Odoo 搜索候选为什么有时就是找不到：_name_search 重写思路和候选命中讲透

先说结论

很多 Odoo 下拉候选“就是搜不到”的问题，根因常常不是界面，而是：

系统到底按哪些字段、按什么优先顺序去命中候选记录。

而这背后特别常见的入口，就是 _name_search。

为什么它常被误会成前端问题

因为用户最直接的体验是：

• 我在候选框里输了关键字
• 怎么没出来？

所以第一反应经常是：

• 前端搜索控件不行
• 刷新慢
• 下拉有 bug

但在 Odoo 里，很多候选命中行为其实主要由模型层决定。

也就是说，前端只是把关键词发出来，真正“怎么找”的核心常常在 _name_search 里。

_name_search 真正最值钱的地方是什么

它最值钱的地方在于：

你可以决定用户用哪些现实记忆方式去找到记录。

用户未必总记得正式名称。

他们可能记得的是：

• 编码
• 手机号
• 邮箱
• 内部参考
• 短名
• 供应商料号

所以 _name_search 的意义，不只是“多搜几个字段”，而是把搜索行为贴近用户真实查找习惯。

为什么它和普通 search 思维不完全一样

因为 _name_search 常常服务的是：

• 下拉候选
• 快速定位
• 交互时即时选择

这类场景的特点是：

• 用户输入短
• 希望马上有结果
• 候选结果必须尽量可辨认

所以它的重点不只是“能不能查出来”，还包括：

• 命中顺序是否合理
• 噪音是否太多
• 体验是否足够快

为什么“字段越多越好”通常是错觉

因为搜索字段一多，就更容易：

• 命中噪音
• 返回过宽
• 顺序变乱
• 性能变差

所以好的 _name_search 重写并不是“把所有字段都 OR 一遍”，而是：

• 先想清哪些字段最符合用户真实输入习惯
• 再决定命中优先级和范围

这比盲目扩字段重要得多。

一个特别实用的设计思路

重写时我更建议先问：

1. 用户通常会输入什么来找这类对象？

这是命中字段设计的起点。

2. 如果多个字段都能命中，哪个更该优先？

这决定结果质量。

3. 哪些字段虽然能搜，但只会制造噪音？

这决定体验是不是“越搜越乱”。

实战里最容易踩的 5 个坑

1. 把 _name_search 当普通 search 拼法照搬

候选体验会很一般。

2. 盲目加字段，不考虑用户输入习惯

结果质量会下降。

3. 只想命中率，不想噪音率

用户反而更难选。

4. 不关注候选搜索的性能

一旦数据量上来就变卡。

5. 只从开发者命名习惯出发，不从业务用户记忆方式出发

这是最核心的偏差之一。

一句话记忆法

把它记成一句话：

_name_search 的核心价值不是“搜更多字段”，而是让候选命中方式更贴近用户真实找对象的习惯，同时控制噪音和顺序。

理解这一句，下拉搜索体验会提升很多。