HTML渠道标识必须在构建阶段注入，而非JS运行时拼接；Webpack需通过templateParameters传入环境变量并用EJS模板渲染，Sails.js则借助sails-linker自定义区块注入；同时需协同配置CDN缓存策略与API网关路由以保障一致性。
HTML渠道标识必须在构建阶段注入，不能靠JS运行时拼接
渠道标识（如 channel=wechat_h5、channel=app_browser）一旦写死在 HTML 里，就失去多渠道分发意义；但若试图用 JS 在 window.onload 里读 URL 参数再改 <script src> 或埋点字段，会出三类问题：首屏资源已按原始路径发出、CDN 缓存无法刷新、跨标签页状态不一致。真正可行的路径只有一条：把渠道上下文带入构建流程，让 HTML 模板在生成时就固化标识。
Webpack 场景下用 html-webpack-plugin 的 templateParameters 注入渠道变量
直接在 webpack.config.js 里写 new HtmlWebpackPlugin({ template: 'src/index.html', hash: true }) 不行——它只加资源哈希，不处理业务维度的渠道参数。正确做法是：
- 构建命令传参，例如
cross-env CHANNEL=wechat_h5 webpack --mode production - 在
HtmlWebpackPlugin配置中使用templateParameters函数，读取process.env.CHANNEL并透传到模板 - HTML 模板需支持 EJS 或类似语法，例如写成
<meta name="channel" content=""> - 同时可在 JS 入口里通过
window.__CHANNEL__ = ''暴露给运行时逻辑
Sails.js 中通过 sails-linker + 自定义注释区块注入渠道字段
Sails.js 的 hash 任务只管文件重命名和生成 .linker.json，真正改 HTML 的是 sails-linker。它默认只处理 <!--SCRIPTS--> 和 <!--STYLES-->，但支持自定义区块：
- 在 HTML 里加注释标记，例如
<!--CHANNEL_ID--><span id="channel-id" style="display:none"></span><!--END_CHANNEL_ID--> - 修改
tasks/config/sails-linker.js，在js或css区块配置之外，新增custom类型区块，并指定正则匹配/<!--CHANNEL_ID-->[\s\S]*?<!--END_CHANNEL_ID-->/ - 注入逻辑里读取环境变量
process.env.CHANNEL，生成替换字符串<span id="channel-id" data-channel="wechat_h5"></span> - 确保
prod环境也启用该区块，否则上线后字段丢失
渠道标识写入位置与缓存策略必须协同设计
写了 <meta name="channel"> 或全局变量还不够，容易踩两个坑：
立即学习“前端免费学习笔记（深入）”；
- 如果 HTML 本身被 CDN 缓存了 1 小时，而你刚切完渠道配置，用户拿到的仍是旧标识——必须确保 HTML 响应头含
Cache-Control: no-cache, must-revalidate，且服务端或 CDN 支持基于 query 参数（如?channel=xxx）做缓存键分离 - 渠道字段若用于后续资源加载（如
fetch(`/api/chat?channel=${window.__CHANNEL__}`)），要确认 API 网关能识别并路由该参数，而不是只依赖 Cookie 或 Header - 多个渠道共用同一套静态资源（如 JS/CSS）时，这些资源不能带渠道哈希——它们是通用的；渠道差异只体现在 HTML 入口层和运行时行为分支上
最易被忽略的是：渠道标识一旦注入 HTML，就成为页面不可分割的一部分，后续所有资源加载、埋点上报、AB 实验分流都依赖它的一致性。构建时漏传、模板未渲染、CDN 缓存未剔除，任意一环断裂都会导致渠道数据错乱，且难以回溯。
