租户隔离必须全程受控：网关透传X-Tenant-ID为唯一可信源，data-tenant-slug仅作展示，禁止class/id拼接租户信息，v-html不提供隔离，SSR需校验JWT与路由一致性，CDN须Vary: Tenant-ID，模板路径不可动态拼接。
租户标识不能塞进 class 或 id 里
很多人图省事，把租户 slug 直接拼进 class="user-list-acme" 或 id="header-acme"，结果导致样式泄漏、JS 误读、甚至被爬虫抓取到跨租户路径。这些属性会被 CSS 选择器、表单提交、第三方调试工具直接消费，根本不是隔离边界。
真正该做的只有两件事：
- 用带命名空间的
data-tenant-slug="acme"属性挂载在根节点或容器上，仅用于展示层或主题切换 -
class只保留通用语义（如theme-dark），具体配色通过 CSS 变量注入，比如style="--acme-primary: #2563eb;" -
id必须静态或语义化（如id="main-content"），绝不拼接租户信息
v-html 和 dangerouslyUseHTMLString 不是租户隔离开关
Vue 的 v-html 或 Element Plus 的 dangerouslyUseHTMLString 本质是绕过转义的渲染通道，它们不识别租户上下文，也不校验来源。哪怕你传入的是 <div data-tenant-slug="acme">...，它照样原样输出——但这个属性对安全毫无帮助。
常见错误包括：
立即学习“前端免费学习笔记（深入）”；
- 用
v-html渲染用户输入的富文本，再靠data-tenant-slug判断是否允许操作 —— 前端属性可篡改，完全无效 - 把租户 API 路径写死在 HTML 字符串里，如
<a href="/api/v1/acme/orders">—— 缓存污染、历史泄露、越权风险全都有 - 依赖
data-tenant-role="admin"控制按钮显隐 —— 应由后端返回的权限字段驱动，而非 DOM 属性推断
SSR 输出的 data- 属性必须与服务端上下文强绑定
服务端渲染时，data-tenant-slug 看似方便，但它只是“快照”，不是信任源。如果 SSR 模板从 cookie 或未签名 header 提取租户 ID，攻击者就能伪造请求头，让页面渲染出其他租户的数据。
安全链路只有一条：
- 租户识别唯一可信源是网关透传的
X-Tenant-ID请求头，或 HttpOnly Cookie 中经签名的值 - SSR 模板中注入的
data-server-tenant-id仅用于调试，前端 JS 绝不读取、不传、不构造 URL - CSR 初始化时，必须比对 JWT payload 中的
tenant_id与当前路由段（如/t/acme/）是否一致，不一致立即报错退出 - CDN/Edge 缓存必须禁用或加
Vary: Tenant-ID响应头，否则缓存会混租户
Go 的 html/template 不等于租户安全
Go 的 html/template 确实能防 XSS，但它只管转义，不管租户。如果你在模板里写 {{.TenantBasePath}}/orders，而 TenantBasePath 来自用户可控输入，那它照样被转义成安全字符串——但拼出来的 URL 仍是错的、越权的。
关键点在于：
-
template.HTML类型绝不能用于租户动态路径或权限判断字段，只适用于服务端预生成的、已白名单过滤的静态片段 - API 基础路径必须由网关统一注入响应头，或构建时固化，不能运行时从模板变量拼接
- 多租户模板复用时，不要用
{{define "acme-header"}}这种硬编码命名，而是用{{define .TenantSlug "-header" | printf "%s%s"}}动态生成，避免模板命名冲突
