目录价格规则在后台显示 Active，商品页还是原价。以前遇到这种情况我也会直接跑全量 reindex，后来发现这只能覆盖一部分原因：索引可以成功生成一份“没有匹配商品”的结果，命令照样返回成功。

先证明这件商品真的命中规则

把条件缩到最小，只保留一个可明确验证的 SKU 或属性。确认 Website、Customer Group、生效日期和商品在当前 store view 的属性值。用于规则的属性如果刚改过“Use for Promo Rule Conditions”，也需要让相关索引和缓存认识到新配置。

特殊价格和目录规则同时存在时，前台通常取可用的最低价格。商品本来就有更低的 special price，会让人误以为规则没执行。测试时记录 regular、special、rule 三种价格，不要只盯最终数字。

看价格索引状态和Cron，不要只看命令最后一行

bin/magento indexer:status catalogrule_rule catalogrule_product catalog_product_price
bin/magento indexer:reindex catalogrule_rule catalogrule_product catalog_product_price
bin/magento cron:run --group=index

Update by Schedule 模式依赖 cron 和 changelog。索引显示 Ready 不代表刚修改的规则已被消费，还要看 mview_state 的版本是否推进、cron_schedule 中相关任务是否成功。生产环境不要习惯性把所有索引切成 Update on Save，它可能把后台保存规则变成一个很重的同步操作。

直接对照索引表比反复清缓存更快

用产品 ID、website ID、customer group 和日期查询规则索引，确认是否产生记录以及 rule_price 是多少。没有记录就回到匹配和索引链路；有正确记录但页面错误，才检查价格缓存、全页缓存和第三方价格插件。

多网站项目尤其容易把规则建在默认网站，却在另一个网站测试。Catalog Price Rule 的作用范围不是仅靠 store view 名称判断，数据库里的 website_id 才是关键。

修复后我会用游客和目标客户组各打开一次商品页、分类页和购物车，并等跨过一个日期边界再确认 cron 能自动切换。一次手工 reindex 能让价格出现，不等于线上调度已经恢复。