语言切换器链接被缓存固定时先别急着清整站缓存

问题出现时，先分清是谁的环节

语言切换器的链接被缓存固定住，表现往往很直接：后台已经改了多语言配置，前台点切换还是跳到旧地址，或者切换后落在一个不再对应的页面上。遇到这种情况，建站方最容易做的动作是清整站缓存，平台侧容易怀疑是多语言组件本身出了问题，客户则往往只看到“切换不管用”这一个结果。三方视角不同，处理动作就容易重叠或者互相等待。双知科技在协助排查这类问题时，通常先把环节拆开，而不是一上来就动全局缓存。

拆环节的意义在于，语言切换器链接被缓存固定，可能发生在生成、存储、输出中的任意一段。谁负责哪一段，先讲清楚，后面才不会出现“都以为对方在查”的空档。

建站方：确认配置与页面输出的对应关系

建站方掌握的是站点配置和页面结构这一层。需要确认的事情不复杂，但要求逐项落实：多语言开关是否只启用了一套逻辑，语言切换器挂在哪个模板位置，切换链接是按当前页面动态生成还是写成了固定值，页面缓存策略是否对切换器所在区域做了整页缓存。这几项里任何一项没对齐，链接都可能被固定在一个旧状态上。

这里有一个容易忽略的点：语言切换器链接被缓存固定，并不等于缓存插件一定有问题。如果切换链接本身在模板里就是静态写入的，那么无论缓存怎么清，输出都不会跟着页面变化。建站方要做的，是先看输出结果，再回看配置来源，而不是把清缓存当成第一步动作。顺序反了，后面每一步判断都会失去参照。

平台侧：判断组件行为与缓存机制的交互

平台侧负责的是多语言组件、缓存机制以及两者之间的衔接逻辑。这一层的判断需要建立在建站方已经确认过配置和输出的前提上，否则平台侧拿到的信息是不完整的。平台侧要看的，是切换器生成的链接是否参与了页面级缓存、缓存键是否包含语言维度、切换动作是否触发了对应的缓存更新。如果缓存键没有把语言区分开，那么不同语言的页面就可能共用同一份缓存结果，链接自然会被固定成先写入的那一个。

这一段的逻辑讲完整需要一点耐心：平台侧不是去替建站方改模板，也不是去替客户判断业务需求，而是确认组件在现有缓存策略下会产出什么行为。行为确认了，责任边界才清晰。如果组件本身按语言维度生成链接、缓存键也带了语言标识，那么链接被固定就更可能出在页面输出或缓存回填环节，而不是组件设计缺陷。反过来，如果组件输出本身就不区分语言，那问题就要回到配置层去解决。平台侧给出的结论应当是行为描述，而不是一句“缓存问题”。

客户侧：提供可复现的观察，而不是结论

客户侧能提供的最有价值的信息，是可复现的观察。哪个页面、切换成哪种语言、期望落到哪个地址、实际落到哪个地址、是否每次都能重现。这些信息比“切换坏了”更能帮助定位。客户不需要判断是缓存还是组件，也不需要先自行清理浏览器数据再反馈，因为那样反而会丢掉现场。

观察要具体。页面要具体。语言要具体。地址要具体。

客户侧还有一个配合动作值得说明：如果站点有多个语言入口，反馈时最好说明是从哪个入口进入、切换后是否刷新过页面。这些细节不影响责任划分，但会影响排查起点。起点准了，建站方和平台侧就不必从最外层重新走一遍。

边界清楚之后，动作才不会互相覆盖

三方各自动作一旦重叠，最常见的后果是现场被反复破坏：建站方清了整站缓存，平台侧拿不到原始缓存状态；客户刷新了浏览器，复现路径断了；再回头查，只能靠推测。语言切换器链接被缓存固定这类问题，本身并不复杂，复杂的是多方同时动手之后，判断基准消失了。

所以分工边界的意义不是推责任，而是保住判断依据。建站方守住配置与输出这一层，平台侧守住组件行为与缓存机制这一层，客户侧守住可复现观察这一层，三层信息合起来，才能判断链接固定发生在哪一段。哪一段归谁，事先说清楚，处理时就不需要靠猜。

如果三层都确认过，链接仍然被固定，那才需要往更细的缓存回填时序或者多语言路由规则里继续找。到那一步，再谈清整站缓存也不迟。