API 明明传了多个过滤条件，结果却像只应用了其中一个，或者一条数据都没有。SearchCriteria 的布尔结构容易写反：不同 filter group 组合为 AND，同一 group 内多个 filter 通常组合为 OR，自定义 Repository 还可能错误实现处理器。
先固定复现条件和影响范围
先把请求缩减到单个字段单个值，再逐个增加条件。保存解码后的查询参数、返回总数和一条应命中、一条不应命中的实体，避免只看第一页。
curl -G 'https://shop.example.com/rest/V1/products' --data-urlencode 'searchCriteria[filter_groups][0][filters][0][field]=status' --data-urlencode 'searchCriteria[filter_groups][0][filters][0][value]=1' --data-urlencode 'searchCriteria[filter_groups][1][filters][0][field]=sku' --data-urlencode 'searchCriteria[filter_groups][1][filters][0][value]=ABC%' --data-urlencode 'searchCriteria[filter_groups][1][filters][0][condition_type]=like'
grep -R --line-number 'FilterProcessor|CollectionProcessor' app/code 2>/dev/null根据证据分支定位
单条件正确、加入第二组后为空，检查期望是否真的是 AND；两个 filter 放同组后数据变多，说明 OR 生效；服务端日志看到括号或百分号被破坏，检查客户端 URL 编码。自定义接口若完全忽略条件，检查 Repository 是否调用 collection processor。
修复时保留回滚路径
先用标准 SearchCriteriaBuilder 在集成测试中表达目标逻辑，再让 REST 客户端生成等价参数。复杂的嵌套布尔条件不要硬塞进不支持的结构，可设计明确的服务接口；禁止把客户端字段直接拼接成 SQL。
上线验收
用真值表准备四条数据，覆盖仅满足 A、仅满足 B、同时满足和都不满足。校验 total_count、分页、排序以及特殊字符值，API 与 Repository 集成测试结果必须一致。
生产环境操作前的检查
处理“Magento 2 REST SearchCriteria 的 AND 与 OR 条件写反”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近一次发布。所有 SQL 默认先执行 SELECT；任何写操作、目录清理或配置切换都应确认影响范围、保留备份并准备回滚。多节点环境要核对各节点代码版本、app/etc/env.php 配置摘要与流量分布。
php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费或订单的改动，先在脱敏数据副本验证。
建立可比较的排查记录
每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。准备一个正常对象与一个异常对象对照；若旧对象恢复而新对象仍能复现，说明根因尚未消除。
| 检查层 | 需要保存的证据 | 通过标准 |
|---|---|---|
| 入口层 | URL、状态码、请求 ID、节点 | 路由和协议一致 |
| 应用层 | 异常堆栈、模块、作用域 | 无新异常且可重复 |
| 数据层 | 主键、时间、关联行数 | 关系完整且无重复副作用 |
| 业务层 | 正常、失败、重试路径 | 最终结果一致 |
修复后的观察窗口
上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器和目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。
