在分类后台把重点商品拖到最前，前台刷新后顺序没有变化，甚至每个客户看到的都不同。Position 只是分类与商品关系上的排序值，只有列表当前 order 选择“Position”时才会生效。

先把 URL 参数清干净

分类页的 product_list_order、product_list_dir 可能被浏览器、主题或 Session 保留。用无痕窗口打开不带 query 的分类 URL，观察 Toolbar 当前选项。后台 Category → Display Settings 的 Default Product Listing Sort By 必须允许并选择 Position。

数据库确认位置值

SELECT cp.product_id, p.sku, cp.position
FROM catalog_category_product AS cp
JOIN catalog_product_entity AS p ON p.entity_id = cp.product_id
WHERE cp.category_id = 42
ORDER BY cp.position ASC, cp.product_id ASC
LIMIT 50;

多个商品 position 相同，数据库对并列行不保证业务期望的次序，应有稳定的第二排序键。导入程序若每次把 position 重置为 0，后台手工调整会在下一轮同步后丢失。

主题可能覆盖默认 order

检查 Toolbar、collection plugin 和 layout 参数。某些主题为了“新品优先”强制 created_at，或从 Cookie/localStorage 恢复上次排序。先临时切到标准逻辑对比，再修自定义模块，不要直接改核心 Toolbar。

搜索引擎参与时的差异

部分版本/扩展让分类集合经过搜索引擎，相关性、库存和置顶规则可能与 position 组合。检查最终 collection 的 order 条件与搜索请求，而不是只看关系表。分类索引陈旧时可以重建作为诊断；若之后再次错乱，要修增量索引或导入触发。

缓存与客户端渲染

FPC/CDN 可能返回旧 HTML，Ajax 分页又可能从 API 取得新顺序。分别看初始源码和滚动加载请求。清缓存后正确不代表根因已解决，需要确认分类保存会产生正确的缓存失效标签。

修复后调整三个商品为明确不同的 Position，验证第一页、第二页、升降序切换、登录/未登录和缓存命中。默认顺序正确，同时用户主动选择价格排序仍应有效，这才是完整结果。

分页边界需要稳定次排序

大量商品 position 相同又没有第二排序键时，同一商品可能在翻页时重复或消失，因为数据库每次对并列行的返回顺序不保证一致。自定义排序应追加 entity_id 等稳定字段，同时确保 Ajax 与初始页面使用同一 order。修复后连续刷新并翻页，结果集合和顺序都应稳定。

如果使用 Visual Merchandiser 或第三方置顶规则，还要记录规则运行时间和手工 Position 的优先级。自动规则重新执行后覆盖人工排序属于配置结果，不是数据库随机变化；运营侧需要明确哪一种排序拥有最终控制权。