Serverless环境下HTML拼接应在构建阶段完成而非运行时。Webpack/Vite等工具将模板、数据、资源编译为带哈希的静态HTML文件，函数仅返回该文件，避免XSS、路径错误、结构错乱等问题，并确保CDN缓存与版本一致性。
Serverless环境下HTML不能靠运行时拼接
直接在函数里用字符串拼接 HTML 片段（比如 res.send('<html>'+header+' '+content+'</html>')）是危险且低效的。Serverless 函数冷启动快，但每次执行都要重新解析、转义、注入——稍有不慎就 XSS，路径错位导致资源 404，多文件合并时重复 <html> 或缺失 <body> 更会让浏览器渲染异常。
- 用户输入未转义就塞进
innerHTML或模板字符串，<script>alert(1)</script>立刻执行 - 拼接多个 HTML 文件时没剔除
<head>/<body>，最终文档结构嵌套错乱 - 相对路径如
src="js/app.js"在拼接后仍按函数执行路径解析，而非部署根路径 → 404 - Node.js 读取文件默认不处理 BOM，Windows 下的 UTF-8 文件开头带
\uFEFF，导致JSON.parse()直接报Unexpected token
构建时拼接才是 Serverless 的正解
真正适配 Serverless 的 HTML 拼接发生在构建阶段：Webpack/Vite 把模板、数据、静态资源一起编译成确定的、带哈希的单个 HTML 文件，函数只需原样返回它。这样既规避了运行时风险，又让 CDN 缓存生效。
-
html-webpack-plugin的template选项支持 EJS/Pug，可安全注入环境变量：<meta name="env" content="<%= htmlWebpackPlugin.options.env %>"> - Vite 用户用
vite-plugin-html的inject配置传入 JSON 数据，再配合transformIndexHtml钩子读取并注入片段，避免手写字符串 - 所有
src/href必须用模块导入（import './logo.svg'），才能被构建工具识别并重写为带哈希的路径 - 禁止在 HTML 模板里写硬编码路径如
./css/main.css—— 构建工具无法替换，上线后永远加载旧资源
动态内容必须走 JS 注入，而非服务端拼接
Serverless 函数不该承担“渲染 HTML”的职责；它只该返回轻量 JSON 或预生成的 HTML 字符串。真正的动态内容（如文章列表、计数器）由前端 JS 通过 fetch 加载，再用 insertAdjacentHTML 或 template 元素安全插入。
- 用
DOMParser解析远程 HTML 片段：new DOMParser().parseFromString(htmlStr, 'text/html')，比innerHTML更可控 - 插入前手动清理脚本：
fragment.querySelectorAll('script').forEach(s => s.remove())，防止意外执行 - 懒加载场景下，用
IntersectionObserver监听占位节点，触发fetch('/api/articles?page=2')，而非让函数每次拼接整页 - 计数器类小工具（如
page-counter）应打包为独立 JS，通过<script src="counter.min.js"></script>引入，函数只提供 API 接口
版本对齐靠构建产物，不是靠运行时逻辑
HTML 文件本身是版本锚点，它的内容决定了该加载哪套 JS/CSS。Serverless 架构下，这个锚点必须由构建过程固化，不能靠函数运行时“动态决定”。
立即学习“前端免费学习笔记（深入）”；
- 构建时把版本号注入全局变量：
window.__APP_VERSION = "v2.3.0-a1b2c3"，JS 用它校验离线资源是否匹配 - Service Worker 的
cacheName必须含版本，如'pages-v2.3.0'；否则新 SW 会误读旧缓存 - 不要在函数里读取
process.env.VERSION然后拼 HTML —— 这个值可能和实际部署的静态资源哈希不一致 - CDN 回源路径要精确到文件名哈希，例如
/index.a1b2c3.html，而不是/index.html（后者易被缓存污染）
url() 函数（如 CSS 中的 background: url(./img/logo.png)）同样受构建工具控制；如果路径没被模块系统识别，就不会重写，上线后必然 404。 
