html模板不能直接发布为npm包，必须封装js包装器并配置package.json的main/exports字段，构建时保留原始结构，灰度与回滚依赖服务端路径分流而非前端逻辑。
HTML 模板本身不支持模块化导入、版本隔离或依赖管理，直接把它塞进前端工程化流水线做“组件发布”，会卡在构建、复用、回滚三个环节。真要让 HTML 片段像 React 组件一样被管理、复用、灰度发布，得绕过“纯模板”思维，转而用工程化手段给它套壳。
HTML模板怎么参与 npm 包发布流程
纯 HTML 文件无法被 npm publish 直接识别为可安装模块——package.json 中必须声明 main 或 exports，且指向可执行/可导入的入口（如 index.js）。所以不能把 header.html 直接扔进 files 字段就完事。
- 必须封装一层 JS 包装器：例如导出一个返回字符串的函数
renderHeader()，内部读取./templates/header.html（通过fs.readFileSync或构建时内联） -
package.json中设"type": "module"，并用exports显式声明 HTML 模板路径（如"./templates/*.html"），否则工具链（Vite/Webpack）无法按需解析 - 构建产物需保留原始
.html文件结构，否则下游项目import时路径失效；建议用rollup-plugin-html或自定义插件做静态资源透出
为什么 HTML 模板不能直接走 Git Tag + CI 自动部署
Git Tag 触发的 CD 流水线（如 GitHub Actions 监听 git push --tags）默认面向构建后产物（dist/），但 HTML 模板若未经过构建处理，直接推 tag 会导致：
- CD 流程找不到可部署内容——
actions/checkout拉下来的是源码，不是渲染后的页面 - 没有构建步骤时，
peaceiris/actions-gh-pages这类插件会把整个仓库（含src/、test/）一股脑上传，暴露敏感路径 - Tag 名称（如
v1.2.0）和实际模板变更无绑定关系：改了一个footer.html却忘了打 tag，下游无法感知版本差异
解决办法是强制所有模板变更走 npm version，由脚本自动更新 package.json 并生成 tag，再触发 CD —— 不是“HTML 变了就发版”，而是“包版本变了才允许上线”。
HTML 组件如何支持灰度与回滚
HTML 模板没有运行时加载机制，所谓“灰度”只能靠服务端路由或 CDN 路径分流实现，而非前端代码逻辑控制。
- 静态资源必须带版本前缀：如
/templates/v1.2.0/header.html，避免浏览器缓存覆盖旧版 - CDN 配置需支持基于请求头（如
X-Stage: canary）或 Cookie 的路径重写，把请求导向不同版本目录 - 回滚操作不是删文件，而是切回上一版的 CDN 路径别名（如把
/templates/latest指向v1.1.0），否则直接删v1.2.0目录会导致 404 - 禁止在 HTML 模板里硬编码版本号——所有版本信息应由构建时注入环境变量或 JSON 配置，否则每次改版都要手动搜替换
前端工程化中 HTML 模板最容易被忽略的兼容性点
多数人只关注“能不能部署”，却忽略模板在不同构建工具下的解析行为差异：
- Vite 默认不处理
.html后缀的 import，需配置server.fs.allow并启用@vitejs/plugin-basic-html插件 - Webpack 5+ 的
asset/source类型能原样输出 HTML，但若用了html-loader，会把img src="logo.png"转成 base64，导致模板脱离上下文后图片失效 - ESLint 和 Prettier 对
.html文件默认不生效，需单独配eslint-plugin-html和prettier-plugin-html，否则格式混乱影响 diff 可读性
真正难的不是让 HTML 上线，而是让它在各种工具链里保持语义一致、路径可靠、版本可溯——这些细节没对齐，自动化就只是把人工错误批量复制了一遍。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
