为什么写这篇

安全这件事,讲概念的多(纵深防御、最小权限、fail-closed),讲工程落地的少。一篇好的安全文章应该能回答:这些概念具体落在哪几行代码里、它们怎么串成一条链、出过什么洞、怎么修的。

这篇文章拆解一个真实仓库 go-wind-shop(GitHub: https://github.com/tx7do/go-wind-shop, Gitee: https://gitee.com/tx7do/go-wind-shop)的安全实现。它不讲"应该做什么",讲"实际做了什么、实际踩过什么坑、实际怎么修的"。文中会引用四个真实的 git commit,每个都是一个被修的安全洞——从漏洞存在、到发现、到修复代码,完整还原。

为什么再聊"契约驱动"

"契约驱动(contract-driven)"这个词被用滥了。大多数项目里它的实际含义是:后端写完接口,用 Swagger 注解生成一份文档,前端照着文档手写 fetch。文档和实现谁是事实源?没人说得清。接口改了文档没改,文档改了实现没改,前后端各自演进直到某天线上 404。

这篇文章不讲概念,讲一个可运行的工程闭环:以 .proto 为唯一事实源,一次 buf generate 同时产出六路产物——后端 gRPC 桩、后端 HTTP 桩、错误码 helper、请求校验器、PII 脱敏器、OpenAPI 文档,以及给前端的 TypeScript 客户端。文中所有配置和代码都来自一个真实仓库 go-wind-shop(GitHub: https://github.com/tx7do/go-wind-shop, Gitee: https://gitee.com/tx7do/go-wind-shop),你可以逐行核对。

一个常见误解

很多团队对"国际化"的理解停留在前端字符串翻译——zh.json/en.json 切换一下 t('hello') 就完事。但对电商而言,真正的难点不在 UI 文案,而在商品内容的多语言化。

一件商品的中文名、英文名、商品描述、类目路径——这些是入库的业务数据,不是 UI 文案。你不能把它们塞进 zh.json,因为:

• 不同语言的商品描述要分别审核、分别上下架。
• 同一件商品的"主数据"(SKU、价格、库存、类目归属)是语言无关的,只有"展示文案"按语言分叉。
• 后台编辑时,运营要在同一界面同时维护所有语言版本,而不是切来切去。
• 店铺前台要能按 URL 里的 locale 一次性取到对应语言版本,而不是取全量再前端过滤。

这篇在讲什么

大多数微服务架构的文章停在"我们用了 BFF 模式"这种结论性描述,不讲 BFF 具体怎么装配、一个请求实际穿过了哪些代码、依赖图是怎么织起来的。这篇文章反过来:用一条真实的 POST /admin/v1/mall/brands 请求,把它从 HTTP 入站到 Ent 落库的每一个环节用代码钉死,再把支撑这条链路的 Wire 依赖注入和运行时配置逐行拆解。

文中所有代码和配置都来自一个真实仓库 go-wind-shop(GitHub: https://github.com/tx7do/go-wind-shop, Gitee: https://gitee.com/tx7do/go-wind-shop),标注了文件路径可核对。读完你会清楚三件事:这条链路怎么走、它由哪些配置决定、依赖图怎么从代码生成。