Shopware6 装饰器修改商品价格后价格筛选功能异常

• 基于官方AbstractProductPriceCalculator示例实现动态改价逻辑，可将后台录入的任意商品价格动态调整为指定值（如1欧元），目前前端价格展示、商品价格升/降序排序功能均运行正常
• 店面默认价格区间筛选功能异常：筛选逻辑读取后台录入的原始商品价格，无法识别装饰器修改后的动态价格
• 异常截图：

装饰AbstractProductPriceCalculator的逻辑仅在PHP层价格计算流程中生效：购物车算价、商品详情/列表渲染输出价格、PHP层遍历商品集合做排序时，都会走到该装饰器逻辑，因此上述场景功能正常。
但Storefront的价格区间筛选属于数据库层直接执行的SQL查询逻辑：筛选条件直接匹配product表存储的原始价格字段，整个查询阶段不会启动PHP层的价格计算流程，自然无法识别装饰器修改后的动态价格。此外前端价格滑块的最大/最小可选值也是通过SQL聚合查询原始价格生成的，不做适配的话滑块区间也会和实际动态价格不匹配。

方案1：装饰产品列表查询逻辑，下沉价格规则到SQL层（推荐，性能最优） #

这是兼容原生筛选逻辑改动最小的方案：

1. 装饰产品列表加载核心类ProductListingLoader、商品网关ProductGateway的查询构建方法，拦截价格区间筛选的条件拼接逻辑
2. 将原本匹配product.price原始字段的筛选条件，替换为符合你动态价格规则的SQL判断：如果是全店统一固定价这类简单规则，直接改写区间匹配逻辑为固定值判断即可；如果是不同商品对应不同动态价的复杂规则，可以提前将动态价格冗余存储到商品自定义字段，查询时直接匹配自定义字段，或通过SQLCASE WHEN语法实现规则判断
3. 同步装饰价格极值的聚合查询逻辑，将动态价格的最大/最小值返回给前端，保证价格滑块的可选区间和实际展示价格一致

方案2：事件监听改价+查询层适配 #

如果不想调整已有的价格计算器装饰器逻辑，可以订阅ProductListingResultEvent事件，在事件触发时遍历加载完成的商品集合统一修改价格；同时按照方案1的逻辑，适配数据库层的价格筛选、极值统计查询即可。

注意：绝对不要在查询完成后通过PHP层遍历过滤不符合价格区间的商品，这种做法会导致分页逻辑异常——分页总条数、每页偏移量都是在SQL查询阶段计算完成的，PHP层过滤后会出现单页商品数量不足、空页、分页计数不准的问题。

方案3：固定规则场景直接持久化动态价格 #

如果你的动态价格规则是长期固定的（比如全店统一促销价、特定客户组固定折扣），不需要运行时动态计算，可以通过定时批量处理、后台导入的方式直接将动态价格写入商品对应价格字段，或使用系统自带的高级定价、客户组定价规则实现，原生的筛选、排序、算价逻辑可以自动适配，不需要额外开发兼容逻辑。

• 不要只修改前端价格滑块的参数或前端展示逻辑，后端查询层不做适配的话，返回的商品结果永远不符合筛选条件
• 所有在SQL层执行的价格相关操作（筛选、极值统计、排序）都需要同步适配动态价格规则，只要是直接查数据库原始字段的逻辑，都不会触发PHP层的价格装饰器
• 如果动态价格和用户身份、访问上下文强相关（比如不同登录用户看到不同价格），查询条件中必须带入当前上下文的用户参数做规则匹配，避免出现价格串号的问题

内容的提问来源于stack exchange，提问作者peterlh