静态页面模块化拼接本身不自动带来代码质量保障；它只是把HTML切开，而质量保障必须靠显式设计的检查、约束和流程——否则碎片越多，越容易失控。
拼接后HTML结构校验必须独立做
用 fs.readFileSync 拼接多个 .html 片段，得到的只是一个字符串。即使所有片段单独验证过，拼接后仍可能产生：<body> 嵌套、<head> 重复、<script> 位置错乱等结构性错误。
- 不要依赖“人眼确认”或“浏览器能打开就OK”，必须引入 HTML 验证器（如
html-validateCLI）对最终输出文件做全量扫描 - 验证需在构建流水线中强制执行，失败则中断发布，而非仅本地提醒
- 注意
html-validate默认不校验自定义模板语法（如<%= title %>），需配置ignoreCustomFragments或先预编译再校验
ESLint 不会检查拼接后的 HTML 字符串
eslint-plugin-html 只能解析 .html 文件中内联的 <script>，对纯字符串拼接生成的 HTML 完全无感。你用 fs.readFileSync('header.html') 读进来的内容，在 ESLint 看来就是普通字符串变量，不会触发任何 HTML 相关规则。
- 若拼接逻辑里混了 JS 模板（如
content.replace('{{name}}', user.name)），需额外用eslint-plugin-security检查replace是否含用户输入，防 XSS - 所有拼接入口函数（如
mergeFragments()）应加 JSDoc 标注参数类型与信任边界，避免后续维护者误传未转义数据 - 禁止在拼接层做 DOM 操作（如用
innerHTML = htmlStr），这类操作应严格限定在前端运行时，且必须配合DOMPurify
静态拼接与 EJS 混用时的 lint 配置陷阱
很多团队用 EJS 做主模板，但把部分片段仍存为纯 HTML 并用 include 引入——这时 ESLint 的 eslint-plugin-ejs 和 eslint-plugin-html 规则会互相干扰。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
eslint-plugin-ejs默认把.html文件当纯 HTML 处理，跳过 EJS 语法检查；需手动在.eslintrc.js中为**/*.html显式指定处理器：processor: 'ejs/ejs' - 若片段含
<% include('nav.html') %>，ESLint 无法跨文件追踪nav.html中的变量作用域，容易漏掉未定义变量引用 - 建议统一后缀：EJS 模板用
.ejs，纯静态片段用.html.partial并禁用其被 ESLint 处理，只由拼接脚本读取
真正难的不是把几个 HTML 文件连起来，而是让每次拼接都可审计、可回滚、可定位问题源头——这要求每个片段带明确的 schema 描述（比如 header.html 必须提供 title 和 logoUrl 字段），而不是靠注释或口头约定。
立即学习“前端免费学习笔记（深入）”；
