国际化网站上线测试：语言版本与地区入口验收清单

国际化网站上线前的语言与地区验收，核心是确认每个受支持入口都到达预期 URL、显示正确语言，并按计划回退。先列出支持范围，再逐项记录预期、实际和证据；代理 IP 可提供地区出口变量，但不能代替站点路由配置。

上线前要覆盖哪些地区、语言和入口？

先定三张清单：支持的语言、开放的地区、对外入口（首页、子目录、子域名、带语言参数的推广链接）。三张清单必须交叉——同一个入口在不同地区可能落到不同语言版本，只列清单不交叉，验收时就会漏行。

每一行指定负责人，并分别填写预期、实际、证据和判定。判定分为“通过、失败、待测”；待测不计入通过。核心入口、注册、支付和导航问题可设为发布阻塞，边缘文案差异则按预先约定的严重度决定风险接受，风险接受仍保留失败状态。未列出的组合默认不承诺支持。

覆盖范围按产品实际开放的地区和语言确定；不把未开放地区写进验收清单，也不承诺清单外的组合。

如何用矩阵记录入口的预期和实际结果？

模板字段包括：地区、入口类型、入口 URL、Accept-Language、地区 Cookie、预期 URL、预期语言、预期关键文案、预期状态码、实际 URL、实际语言、实际关键文案、实际状态码、证据、结论。按支持范围逐行展开，未执行的组合填“待测”，待测不计入通过；地区、语言和时区作为独立输入记录，不能互相替代。

每组对照只改变一个变量：测地区差异时固定语言头、Cookie、入口和代理类型，只换地区出口；测语言协商时固定地区出口与其他状态，只改 Accept-Language。记录完整 URL（含查询参数）和最终状态码，不要只写“跳转正常”。同一入口在不同地区落到不同子目录，属于预期差异，要提前写进“预期 URL”列。基础矩阵固定一种代理类型；只有怀疑 CDN 或风控按出口类型区别对待时，才另开类型对照，并记录挑战页与状态码——类型差异不能直接归因为站点地区策略。

首次访问和直接语言链接要分开测试吗？

首次访问测的是“没有历史状态时系统怎么猜”：用清洁会话，分别设置 Accept-Language 和地区 Cookie，观察是否按预期落到语言首页。显式语言入口测的是“用户已经给了明确指令”：直接访问 /de/、?lang=de 或语言子域，系统必须尊重该指令，不能被 IP 地区覆盖。

两类结果要分开记。常见失败有三类：不跳转、落错页、回退 404。举个典型的：请求 /fr/ 却 302 到 /、最终停在英文首页，只能作为待核实现象。先确认 /fr/ 是否已发布、是否在支持语言清单内，再结合 Cookie、语言协商配置和跳转日志判断是产品预期、降级还是路由缺陷。不能只凭最终英文页确定原因。

出口识别与页面地区不一致时，先核对出口 IP 的归属地与站点返回的地区标记，再判断是路由问题还是出口问题；两类记录分开，避免把链路差异写成站点缺陷。

发现偏差后，如何判断是否阻塞上线？

把未通过项按“阻塞 / 风险接受”分级：影响注册、支付、核心导航的算阻塞；仅影响边缘文案且已有兜底的，可记为风险接受，但必须写负责人、修复时间和复验日期。每条偏差保留复现条件（地区、语言、入口、会话状态），否则开发无法复现。

上线结论只写三种：通过、阻塞、风险接受，不要用“基本可用”“问题不大”这类描述。判定依据是矩阵中预先定义的 URL、页面语言、关键文案和状态码，并保留对应证据；没有证据的行保持待测。判定完成后，把矩阵和结论一起归档，下次发版复用同一张表。归档矩阵及偏差处置记录，作为下次发布的基线。

下面用一张已填写的矩阵说明判定方式（示例表只保留判定所需列，完整模板按上述字段展开）：第三行仍为“待测”，不能计入通过项。

先核对实际 URL 与状态码，再核对页面语言：FR 行请求 /fr/ 却落到 /de/，即使状态码为 200，仍因语言不符而失败；JP 行没有实际结果，必须保持“待测”，不能计为通过。

FAQ

必须用代理 IP 才能做这个验收吗？

不是。它只提供“从某个地区访问”的出口变量；能改 Host、能注入地区头的测试环境同样可以测。用代理是为了更接近真实用户的网络位置，不是验收的前提。

子目录和子域名入口，验收标准一样吗？

判定项一样，都是 URL、页面语言、关键文案和状态码；差别在子域名多一次 DNS 与证书检查，回退规则也要单独写，不能照抄子目录。

还没覆盖的入口能不能先上线？

可以，但要走“风险接受”：写清未覆盖的地区与入口、影响面、负责人和补测时间，不能默认视为通过。

验收该用住宅代理 IP 还是机房代理 IP？

基础验收固定一种，结论里写明用的是哪类；只有怀疑 CDN 或风控按出口类型区别对待时，才另开一组对照，类型差异不能直接算作站点地区配置的缺陷。

需要确认可用出口地区，可查看全球代理支持的出口地区。