租户标识应通过带命名空间的data-属性嵌入html，如data-tenant-slug="acme"，挂载于或顶级节点；禁止在class、id、name及表单控件中拼接租户信息；ssr/csr需校验租户一致性并禁用静态缓存或添加vary: tenant-id头。
租户标识如何嵌入HTML属性而不污染语义
多租户系统里，前端需要区分租户上下文，但直接往class或id里硬塞tenant_id是危险的：既破坏CSS可维护性，又可能被JS误读或暴露敏感信息。真正可行的做法是用自定义属性+命名空间约束。
- 统一使用
data-tenant-前缀，例如data-tenant-slug="acme"或data-tenant-role="admin"，避免与未来HTML标准冲突 - 禁止在
id、class、name中拼接租户标识——这些属性常被CSS选择器、表单提交、第三方库（如React DevTools）直接消费，容易引发跨租户样式泄漏或数据混写 - 服务端渲染时，由租户上下文注入属性；客户端切换租户时，必须清空旧
data-*并重写，不能简单merge
动态主题类名该不该用class属性承载租户配置
答案是否定的。class本质是样式契约，不是配置容器。把tenant-theme-dark这类值塞进class，会导致CSS规则爆炸、调试困难，且无法与CSS-in-JS或Shadow DOM隔离机制协同。
- 主题应由CSS变量控制：
style="--theme-primary: #2563eb; --theme-font-size: 14px;"，变量名带租户前缀如--acme-primary - 若必须用类名切换主题，只保留通用语义类（如
theme-dark），具体配色由CSS变量注入，而非靠class匹配大量租户专属规则 - 注意：
class列表长度无限制，但浏览器对class字符串的解析和匹配性能随数量线性下降，百级租户规模下，每个元素平均多出3–5个租户相关class就会明显拖慢重排
data-属性在SSR/CSR混合场景下的同步风险
服务端渲染（SSR）输出带租户data-属性的HTML，客户端再用JS读取并初始化状态——这个链路在多租户环境下极易断裂。
- SSR模板必须严格校验租户上下文来源：不能依赖cookie或header未签名字段，必须通过已认证的租户路由段（如
/t/acme/dashboard）或JWT payload提取tenant_id - CSR端读取
data-tenant-id后，必须与当前auth token中的租户声明比对，不一致则立即报错退出，防止前端伪造租户上下文 - 缓存层（CDN/Edge）若缓存了带租户
data-的HTML片段，会污染后续请求——必须禁用该路径的静态缓存，或添加Vary: Tenant-ID响应头
租户隔离边界在DOM层级上的实际落点
HTML结构本身不是隔离单元，但它是隔离策略的最终承载体。关键不是“怎么加属性”，而是“在哪一级加”。
- 隔离粒度最小单位是
或顶级<div id="app">，所有租户相关<code>data-属性必须挂载在此节点，子组件通过DOM遍历或context继承获取，而非逐层重复写 - 禁止在
<input>、<form></form>等表单控件上写data-tenant-——这些元素可能被序列化提交，导致租户标识意外透出到后端非预期接口 - Web Component场景下，
:host伪类可结合data-tenant-做样式隔离，但需确保custom element的shadowRoot启用closed模式，否则外部JS仍能绕过属性读取内部DOM
租户标识在HTML中的表达，从来不是“加不加”的问题，而是“在哪加、怎么读、谁负责清理”的协作契约。最容易被忽略的是服务端与CDN之间的缓存契约——一个没设
Vary头的租户HTML响应，可能让十个不同租户看到彼此的data-属性。
