Odoo 搜索框为什么有时搜不到：name_search、display_name、搜索体验到底怎么设计

先说结论

Odoo 里很多“下拉搜不到”“结果显示不友好”“用户老选错记录”的问题，核心往往不是前端控件，而是：

• 搜索入口按什么字段找
• 搜到后用什么文本展示
• 多字段搜索策略有没有设计好

这条链最关键的几个点通常就是：

• name_search
• display_name
• 相关显示逻辑

为什么这个问题经常被误判成前端问题

因为用户看到的表象是：

• 下拉框里搜不到
• 搜出来的候选项不直观
• 同名记录分不清

所以很多人第一反应会去怀疑：

• JS 下拉组件
• 前端缓存
• 页面没刷新

但实际在 Odoo 里，这类体验问题常常更靠近模型层。

也就是说：

你在下拉框里看到的搜索体验，很大一部分是后端搜索与显示策略决定的。

name_search 本质上在决定什么

它最核心决定的是：

用户输入关键词时，系统按什么规则去找候选记录。

所以如果你只让它按单一字段搜，用户就只能用那一种记忆方式找对象。

但真实业务里，用户可能会按这些方式找：

• 名称
• 编码
• 手机号
• 邮箱
• 内部参考
• 订单号

如果搜索策略太窄，用户就会觉得“系统明明有这条记录，为什么搜不到”。

display_name 又在决定什么

如果说 name_search 决定“搜不搜得到”，

那 display_name 更接近决定：

搜到以后，用户看到的候选项长什么样。

这非常关键。

因为很多业务对象天然会有重名：

• 联系人同名
• 产品名相似
• 单据标题重复

如果展示只给一个过短名字，用户就容易选错。

所以一个好的显示文本，往往会适当补足辨识信息，比如：

• 编码
• 公司
• 手机
• 邮箱
• 上级名称

为什么“能搜到”和“好不好选”是两回事

这点特别容易被忽略。

你可能已经让系统搜得到，但如果候选列表长这样：

• 张三
• 张三
• 张三

用户体验依然很差。

所以真正好的 Many2one 搜索设计通常要同时解决两件事：

1. 搜索入口足够宽
2. 显示结果足够可辨认

少任何一半，体验都不算真正完成。

为什么搜索策略不应该无脑越宽越好

因为越宽通常意味着：

• domain 更复杂
• 结果更杂
• 性能压力更大
• 噪音命中更多

所以搜索设计不是“字段越多越高级”，而是：

让最符合用户真实检索习惯的几个字段优先可用。

比如客户模型，手机号和邮箱可能很关键； 产品模型，内部编码和名称可能更关键。

要贴业务，而不是炫技巧。

实战里最容易踩的 5 个坑

1. 只按名称搜

一旦重名多，体验马上崩。

2. 搜索字段很多，但显示文本太短

用户能搜到，却选不准。

3. 显示信息过多

候选项过长，反而更难扫读。

4. 不考虑性能

搜索体验会变卡，最终还是不好用。

5. 只按开发者视角设计

用户记的是手机号、编码、简称，不一定记官方全名。

一个特别实用的设计原则

设计搜索体验时，建议先问：

1. 用户平时会用什么关键词找这个对象？

这决定 name_search 的重点字段。

2. 如果有重名，用户靠什么区分？

这决定 display_name 该补哪些信息。

3. 哪些字段真的值得进搜索，哪些只会制造噪音？

这决定性能和准确率。

一句话记忆法

把这条链记成一句话：

name_search 决定用户能不能找到，display_name 决定用户能不能选对。

理解这一句，Odoo 下拉搜索体验设计会清楚很多。