最可靠方式是服务端渲染时由模板引擎注入或静态页由构建脚本替换占位符；严禁js运行时写入，需校验document.documentelement.dataset.env，css用属性选择器控制，且html必须禁用缓存。
环境标识必须在 HTML 初始响应中就存在，不能靠 JS 运行时写入——否则 CSS、首屏逻辑、早期模块都会读错。
怎么往 data-env 属性最可靠
服务端渲染时由模板引擎直接注入，比如 Django 用 {{ ENVIRONMENT }}，Node.js 的 EJS 写成 。纯静态页则靠构建脚本替换占位符，如 Webpack 的 html-webpack-plugin 配置 templateParameters 注入值；Vite 中用 define + 模板里 <script>document.documentElement.dataset.env = '__MODE__'</script>，但该 <script></script> 必须放在 最顶部，且只适用于构建后环境确定的场景。
- 千万别用 JS 在 DOM 加载后动态设置
document.documentElement.dataset.env——getComputedStyle或 CSS 属性选择器此时已计算完毕 - 避免用
document.body.dataset.env，body 可能还没解析完，异步模块里容易读到undefined - 注入值必须是明确字符串，如
"dev"、"staging"、"prod"，别用布尔或数字
为什么不能用 window.location.hostname 判断环境
域名和实际后端环境不总是一一对应：本地开发可能 hosts 映射到 prod.example.com；SaaS 平台常把 staging 和 prod 部署在同一域名不同路径下（如 /app/staging/ vs /app/prod/）；某些灰度流量入口 host 和生产完全一样，仅靠 header 或 cookie 区分。
- 真实案例：
location.hostname === 'admin.example.com'→ 误判为生产，实为灰度 API 流量 - 若非要用 JS 判断，至少 fallback 到检查
document.cookie是否含env=test（需后端 Set-Cookie 注入），或请求/api/v1/env-check接口，但要接受首屏无标识的风险 - 永远别在构建时把
process.env.NODE_ENV当运行时环境——它打包完就固化了，CI 构建的 prod 包如果误发到测试服务器，JS 仍会读出"production"
CSS 里怎么根据 data-env 控制显示隐藏
用属性选择器最直接，比如 [data-env="test"] .debug-panel { display: block; }。这样写不依赖 class 命名冲突，也不需要 JS 参与，DOM 解析完样式立即生效。
- 别用
.env-test这类 class 控制——业务代码可能也用了test作语义，容易覆盖或漏配 - 隐藏不等于安全：DOM 里仍存在敏感内容（如 mock 接口地址），真正要隔离的字段必须从 HTML 源码中彻底剔除，而不是靠
display: none - 构建工具如 Webpack 的
DefinePlugin能让process.env.NODE_ENV === 'production'在 CSS-in-JS 中生效，但对纯 CSS 文件无效
最容易被忽略的缓存陷阱：CDN 返回了带 data-env="test" 的 HTML 给线上用户
这是最隐蔽也最危险的问题。一旦测试环境 HTML 被 CDN 缓存并返回给生产用户，JS 就会调用测试接口、上报埋点到测试监控系统，甚至泄露调试信息。
- 必须确保 HTML 响应头包含
Cache-Control: no-cache, no-store, must-revalidate，尤其对带data-env的页面 - 如果用了 Nginx，注意
sub_filter替换注释时是否开了缓存；如果用了 Cloudflare，检查 Page Rule 是否对 HTML 启用了缓存 - 微前端场景下，子应用不能自己读
document.documentElement.dataset.env——沙箱环境里 dataset 可能不可见，必须由主应用透传
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
