葡语双站共用代码库：货币日期税号按域名切换

发布时间：2026-10-10 08:16 更新时间：2026-10-10 08:16 阅读量：0

做葡萄牙和巴西两个葡语市场，很多企业会先问一个问题：要不要各建一套站？从预算和维护角度看，共用一套代码库、按域名切换展示内容，通常更省人力。但真正做起来，坑往往不在语言翻译，而在同一份代码要给两种完全不同的商业规则让路：葡萄牙用欧元、日期习惯是日在前，税号是 NIF；巴西用雷亚尔、日期习惯是日在前但金额写法差异大，企业和个人分别是 CNPJ 与 CPF。如果切换逻辑没设计好，最典型的事故就是巴西客户看到欧元报价，或者葡萄牙客户的税号栏提示成 CNPJ。

下面从业务视角讲清三件事：为什么要按域名切、怎么切、怎么验收。技术细节交给开发执行，你只需要能看懂判断标准。延伸阅读可先看 建站方案，把站点结构定下来再谈实现。

一、为什么必须按域名切，而不是按语言切

语言和市场的对应关系在葡语里是错位的。葡萄牙和巴西都说葡萄牙语，但货币、税号、日期写法、甚至报价页的措辞习惯都不同。如果系统只判断「语言=pt」，两个市场会拿到同一套字段规则，出错只是时间问题。

更稳的做法是把域名当成第一判断依据：.pt 走葡萄牙规则，.com.br 走巴西规则，语言标签只负责文案翻译。这样即使以后新增 .ao 或 .mz 等市场，也只是加一条域名映射，不用动模板结构。

要注意的是，域名判断不要只看后缀字符串，较实用一份显式配置表，把主域名、备用域名、地区代码、货币、税号类型一次性写清。开发改配置，运营不用碰代码，这是双站长期可维护的关键。

二、三组字段的切换规则与配置示例

先明确每组字段的差异，再谈实现。货币上，.pt 显示欧元并采用逗号小数、点千分位；.com.br 显示雷亚尔，符号通常写作 R$，小数位同样是两位，但千分位与符号位置的书写习惯需要按当地阅读习惯确认，具体以官方文档和当地同事校对为准。日期上，两站都常见「日/月/年」顺序，但月名缩写和是否补零要统一，避免同一站内两种写法并存。税号上，.pt 面向企业与个人常用 NIF，.com.br 企业用 CNPJ、个人用 CPF，表单提示语必须跟着变。

实现层面，推荐在渲染前生成一个「站点上下文」对象，模板只读这个对象，不自己判断域名。下面是一份可参考的配置示例，字段名可按你们项目调整：

# site-context.yaml 示例，按实际项目结构调整
sites:
  pt:
    domains: ["www.example.pt", "example.pt"]
    locale: "pt-PT"
    currency: "EUR"
    currency_symbol: "€"
    decimal_sep: ","
    thousand_sep: "."
    date_format: "dd/MM/yyyy"
    tax_id:
      label: "NIF"
      pattern: "^[0-9]{9}$"
      hint: "个人与企业均填写 9 位 NIF"
  br:
    domains: ["www.example.com.br", "example.com.br"]
    locale: "pt-BR"
    currency: "BRL"
    currency_symbol: "R$"
    decimal_sep: ","
    thousand_sep: "."
    date_format: "dd/MM/yyyy"
    tax_id:
      label: "CNPJ / CPF"
      pattern: "^([0-9]{14}|[0-9]{11})$"
      hint: "企业填 CNPJ，个人填 CPF"

模板里只做一件事：根据当前域名取出对应节点，再把货币、日期、税号字段渲染出来。这样 .pt 永远不会拿到 BRL，.com.br 也不会提示 NIF。

如果站点已经有一定规模，建议把这段逻辑收敛到一处统一的「站点解析器」，其他页面全部调用它。分散判断是后期 bug 的主要来源。

三、缓存键怎么设计，才能不互相污染

共用代码库最容易翻车的地方是缓存。同一份页面模板，如果缓存键只写了页面路径，葡萄牙站生成的 HTML 可能被巴西访客读到，货币和税号全错。缓存键必须把「站点维度」带进去。

合理的做法是让缓存键包含域名或地区代码，而不是包含完整 URL 里的语言参数。例如把 page:home:pt 与 page:home:br 分开存。CDN 层同理，需要在回源请求里携带站点标识，或在边缘节点按 Host 头做区分，避免把 .pt 的响应复用到 .com.br。

另外两点常被忽略。一是表单校验结果不要跨站缓存，税号正则不同，缓存命中会放过错误格式；二是报价金额这类实时数据不宜长时间缓存，货币换算尤其如此。验收时可以让两个域名同时打开同一个页面，对比货币符号、日期样例和税号提示是否各自正确。

四、落地前的准备清单

如果你正准备启动这个项目，可以按下面这份清单推进，逐项确认后再进入开发：

• 确认两个域名的归属与解析都到位，.com.br 在巴西本地注册通常需要当地税号，具体以注册商要求为准。
• 和业务方确认报价页是否需要同时显示本币与欧元，还是只显示当地货币，这直接决定字段数量。
• 整理一份字段对照表：货币符号与小数写法、日期样例、税号名称与位数，让当地同事签字确认。
• 明确缓存策略：哪些页面按站点分别缓存，哪些实时数据不缓存，写进技术方案。
• 准备两套测试数据，至少覆盖企业客户与个人客户，用真实格式的税号做校验测试。
• 上线前做交叉验证：在 .pt 打开巴西客户会看到的页面路径，确认不会出现 CNPJ 提示。
• 把域名与规则配置放进版本管理，后续新增市场时只改配置、不动模板。

需要参考整体结构时，可以再看 模板与定制风格，把页面骨架和字段位先定下来，能省掉后期返工。若你想了解同类多市场项目的组织方式，客户案例 里也有可借鉴的站点结构思路。

共用代码库本身不是问题，问题在于有没有把市场差异显式写进配置与缓存键。把域名当第一判断依据、把字段规则集中管理、把站点维度带进缓存，两站就能长期并行而不互相污染；反过来，任何一处偷懒判断，最后都会变成客户看到的错误报价。

准备做网站，先从哪一步开始？

如果你希望把上面的思路落到自己的行业与目标市场，可以先看 建站方案 了解一站式流程，再对照 客户案例 判断哪些做法适合自己的业务；也可以加微信 tsrz001 沟通需求，把页面结构、预算和排期先聊清楚再动手。

继续阅读