同一个商品，未登录时显示 199 元，客户登录后变成 179 元；或者后台明明没有设置 Group Price，某个客户组仍看到不同价格。Magento 2 的最终价格不是从商品表里读取一个数字，而是商品基础价、特殊价、客户组价、目录价格规则、网站范围、税与币种共同计算后的结果。

先确认差异发生在“价格”还是“显示”

把两个身份的商品页、购物车和接口价格分别记录下来。若不含税金额相同、含税金额不同，优先查客户组对应的税务类别、地址和跨境税规则；若 final_price 本身不同，再进入价格索引。不要只截取页面上的大号数字，主题可能同时显示 regular、final、minimal price。

可以在 GraphQL 中带不同客户 token 查询 price_range，或在 REST/服务层以相同 store view 比较。关键是保证网站、币种、数量和时间一致，否则对比没有意义。

索引表能告诉你是哪一维不同

SELECT entity_id, customer_group_id, website_id,
       tax_class_id, price, final_price, min_price, max_price, tier_price
FROM catalog_product_index_price
WHERE entity_id = 1234
ORDER BY website_id, customer_group_id;

这里每个 website 与 customer_group 都有独立行。某组的 final_price 已经不同，说明差异发生在索引计算之前或之中；索引一致而前端不同，应查税、币种转换、自定义 price renderer 与缓存私有内容。

客户组价只是候选价格之一

商品 Advanced Pricing 中的 Customer Group Price、Tier Price 会与 Special Price、Catalog Price Rule 等候选值比较。对可配置商品，父商品展示价还会由可售子商品聚合；某客户组看不到最低价子商品时，最小价格也会改变。B2B 环境的 Shared Catalog 还能覆盖公共目录价格。

排查时列出该 SKU 的所有价格来源，而不是只查一个属性：

bin/magento indexer:status catalog_product_price
bin/magento indexer:show-mode catalog_product_price
bin/magento indexer:reindex catalog_product_price

手动重建可用于验证索引是否陈旧，但如果重建后恢复、随后又失效，根因通常在 Cron、MView changelog 或某个导入程序没有正确触发变更。不能把定时 reindex 当长期修复。

缓存必须按正确上下文变化

Magento 的页面缓存会通过 HTTP context 区分客户组等上下文。自定义 block 如果直接读取 session，又声明为 cacheable，可能把某个客户组的 HTML 缓存给另一个组。反过来，把整个商品页设为不可缓存也不是修复，只会让性能下降。

检查自定义价格 block 是否使用标准 price renderer；检查 plugin 是否修改 getFinalPrice 却没有提供正确的缓存身份；检查 CDN 是否忽略 Magento 的缓存 cookie。若错误价格只在第一次登录后出现，刷新又正常，重点看 customer-data 与页面缓存切换。

数量、日期和时区也会改变结论

Tier Price 依赖数量，Special Price 与规则可能有起止日期。后台时区、应用时区和数据库 UTC 混用时，切换点附近常出现“某组提前生效”。记录服务器时间、store locale 与价格规则状态，再对比索引生成时间。

一段安全的定位思路

先比较未税 final_price，再用索引表按 website/customer_group 确认差异是否已被计算；然后逐一排除 Group/Tier Price、Catalog Rule、Shared Catalog；最后才查税显示和缓存。修复后至少覆盖访客、普通组、特殊组、不同数量与购物车重算。价格页正确但购物车错误，说明 quote totals 链路仍未修好，不能算完成。