品牌查询在两个地区浏览器里看着一样，返回商品却不同，先比较真实Unicode序列，再判断住宅出口差异。本文面向获授权的商品搜索与市场调研测试，区分查询规范化、路由、索引及展示问题，是受控设计，不报告98IP实测行为或真实搜索排名。
1. 由搜索所有者定义等价
Unicode允许规范等价序列：带重音字母可用一个预组合字符，或基础字母加组合标记表示。NFC与NFD给出不同规范形式；NFKC等兼容规范化还可能消除其他区别，不能盲用。规范化不等于去重音、翻译或大小写折叠。
请所有者明确哪些查询应得等价结果、哪些必须区分。使用小型合成商品目录，独立定义预期商品ID、语言及市场。如果服务有意按精确序列匹配，应记录契约，不能把每个NFC/NFD差异都判故障，也不能擅改第三方输入。
2. 构造可重复输入对
- 在相同合成词中分别使用U+00E9，以及U+0065后接U+0301。从码点生成，不凭手打两个相似外观猜表示。
- 在不含秘密的夹具清单保存码点和UTF-8字节，标明所有者预期。截图不能证明序列。
- 加入刻意不同的对照，例如无重音词，并单独规定预期结果，不自动归入等价类。
- 固定版本、键盘输入法、语言、市场、账户状态、搜索设置与地区，使用相同提交动作。
- 保留原始值，另存明确标注的规范化诊断副本，不在观察前覆盖原输入。
JavaScript测试工具可用指定形式的String.prototype.normalize制作诊断比较，它只确认该形式下字符串等价，不证明搜索索引或排序契约。记录运行时与形式，不用可见字符数代替码点证据。
3. 沿四个边界追踪查询
自有预发布应用分别记录提交前输入、序列化请求、接收端解码查询，以及所有者可提供的搜索实际查找键。每次独立关联，只用合成值，客户真实搜索历史不放共享日志。
用客户端正常URL或正文序列化器编码查询组件一次。百分号编码和Unicode规范化是不同变换，分别比较解码字符串与序列化字节。不要反复解码整个URL，编码分隔符可能是数据。接收端看到百分号而非预期文字，可能是序列化边界错误，不一定是索引问题。
检查展示格式、自动补全选择或输入法组合是否改变提交值。打字与粘贴确有需求时分别测。组合尚未完成就提交，与已确认查询不是同一输入，不能当地区结果对照。
4. 先比商品身份，再比数量
输入对和负例走获准基线及代理路径，固定少量尝试。保持市场、语言、筛选与会话策略，记录出口、夹具索引版本、提交码点、解码值及商品ID。
- 应等价且收件正确，ID却不同：与所有者查搜索分析、索引导入及缓存键。
- 收件序列与确认输入不同：调查首个观察到变化的客户端或序列化边界。
- ID相同但排序或标签不同：另记排序或展示问题，身份等价不证明排名相同。
- 市场或夹具版本不同：对照受干扰，先恢复控制，再归因规范化或出口。
200和结果数量相等不够，不同商品集也能同样大小。合成夹具比较规定ID，只有契约明确要求时才断言顺序。禁止直连时明确缺少基线。
5. 只修约定的规范化边界
自有应用契约要求规范匹配时，选择并记录形式，查询与索引查找表示采用一致规则。按要求保留原文展示或审计。只改查询可能让旧索引不兼容，应计划获准重建或迁移，并验证新旧夹具。
搜索修复不能顺带规范化密码、签名、不透明令牌或商品标识。不要为扩大匹配直接去重音或用NFKC。加入必须保持不同的负例，确认没有误合并；缓存及去重键遵守相同语义，否则可能继续返回冲突旧结果。
第三方调研目标应保留批准的输入规则，如实报告观察，不静默合并记录。规范化去重键是分析选择，不证明真实商品或用户同一。不能从合成案例编造搜索量、排名或地区偏好。
6. 用98IP做地区控制
授权搜索需指定地区时，可查98IP动态住宅IP，依配置文档及账户获取支持参数。核对出口，字符串比较内保持地区与会话稳定。
地区路径可暴露部署或索引版本差异，不替你规范化文字，也不保证相同结果。普通未拦截HTTPS中，代理不能改写加密查询。本文不承诺吞吐、兼容性或失败计费实测。限制流量、核对用量，仅处理获授权数据。
7. 验收清单与常见问题
- 所有者定义等价输入及必须不同的对照。
- 确认输入、传输字节、解码查询、查找键分别可观察，缺失则记未知。
- 夹具版本、市场、语言、筛选、浏览器与会话固定。
- 商品ID通过，数量、顺序及展示另验。
- 按要求保留原值，不改秘密、令牌及无关标识。
截图能证明输入相等吗？ 不能，需看确认值和码点，同外观可能不同序列。
每个查询都应NFKC吗？ 不应。兼容折叠可能抹掉有意义区别，需批准语义与负例。
NFC保证各国相同结果吗？ 不保证，市场、索引、筛选及排序仍可不同。它只控制一个变量。