规则设置从今天开始，零点后前台仍是原价，手工 Apply Rules 后才恢复。Catalog Price Rule 的日期按商店时区判断，最终价格依赖规则数据准备、Cron 和价格索引；服务器 UTC 时间与后台显示时间不同会造成误判。

先固定复现条件和影响范围

记录规则 ID、from_date、to_date、is_active、Website、客户组、Store 时区和一个目标 SKU。比较服务器、PHP、数据库和 Magento 商店时间。

date -u
php -r 'echo date("c"), PHP_EOL;'
mysql -e 'SELECT NOW(),UTC_TIMESTAMP(),@@session.time_zone'
php bin/magento config:show general/locale/timezone
SELECT rule_id,name,from_date,to_date,is_active FROM catalogrule WHERE rule_id=10;
SELECT rule_id,product_id,customer_group_id,from_time,to_time,rule_price
FROM catalogrule_product_price WHERE rule_id=10 LIMIT 20;
php bin/magento indexer:status catalogrule_rule catalogrule_product catalog_product_price

根据证据分支定位

规则表未产生目标商品，检查条件、Website 与客户组；已有规则价格但前台不变，查价格索引和缓存；只在日期边界失败，核对时区转换和 Cron 执行窗口。多规则同时命中时还要检查优先级与停止后续规则。

修复时保留回滚路径

统一 NTP 和 PHP/数据库基础时间，Magento Store 使用正确业务时区；修复 Cron 后重新应用规则并让相关索引正常消费。不要每天用手工 Apply 代替故障的调度链，也不要直接修改 rule_product_price。

上线验收

在测试环境使用临近生效与失效边界的规则，覆盖两个客户组和 Website。规则应自动开始与结束，列表、详情、购物车和订单价格一致，跨午夜无需人工操作。

生产环境操作前的检查

处理“Magento 2 Catalog Price Rule 午夜后没有生效”前，先记录 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 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。