prettier配置必须放在项目根目录，因vs code逐级向上查找配置，若用户家目录存在不同规则的全局配置会覆盖项目配置，导致团队格式化结果不一致。
为什么Prettier配置必须放在项目根目录而非用户家目录
团队协作中，.prettierrc 放错位置会导致成员本地格式化结果不一致——VS Code 会逐级向上查找配置文件，若某人本地 ~/.prettierrc 存在且规则不同，就会覆盖项目配置。实际协作中常见错误是：A 同学提交了“看似格式正确”的代码，B 同学拉取后保存自动触发本地全局配置，瞬间改掉 20 行缩进和引号，引发无意义 diff。
实操建议：
-
.prettierrc必须置于 Git 仓库根目录，且应随项目一起提交 - 在
.vscode/settings.json中显式禁用全局 Prettier："prettier.resolveGlobalModules": false - 用
prettier --check src/**/*.html在 CI 中做校验，失败即阻断合并 - 避免使用
prettier.config.js（需 Node 环境），纯 JSON 或 YAML 更易跨编辑器兼容
HTML语义标签误用在协作中引发的隐性冲突
团队里常有人把 <div class="card"> 当成万能容器，结果多人并行开发时，<code>card 类被不同人赋予完全不同的结构含义：有人塞 <table>，有人放 <code><article></article>，有人甚至嵌套三层 <div> 模拟网格。这类“视觉一致但语义混乱”的代码，在 Code Review 阶段极难发现，却直接导致无障碍测试失败、SEO 权重稀释、后续重构成本翻倍。<p>实操建议：</p>
<ul>
<li>用 <code>htmlhint 配置 "tag-pair": true 和 "attr-no-duplication": true 基础检查
package.json 中加一条脚本："lint:html": "htmlhint --config .htmlhintrc src/*.html"
<div class="list"> 改为 <code><ol class="product-list"></ol>”Git 提交前自动格式化为何常失效
很多人装了 husky 和 lint-staged，却仍出现未格式化代码合入主干的情况。根本原因不是工具没起作用，而是 lint-staged 默认只处理 staged 文件，而开发者习惯先 git add . 再 git commit ——此时所有文件都已暂存，Prettier 修改后不会自动重新 git add，导致格式化变更未纳入本次提交。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操建议：
- 在
lint-staged配置中明确指定执行后自动添加："*.html": ["prettier --write", "git add"] - 避免
git add .，改用git add -u（仅更新已跟踪文件），减少误暂存无关文件 - CI 中补一道防线：
git diff --quiet || (echo "格式化未生效，请检查"; exit 1) - 把
prettier --write加入npm run dev启动脚本开头，确保本地开发环境始终干净
实时协作时光标同步与 DOM 结构冲突的真实代价
CodeSandbox 或 Replit 的实时协同看似流畅，但当两人同时修改同一段 HTML（比如都在往 <header></header> 里加导航项），后台用 OT 算法合并时可能产生非法结构：<nav><a>Home</a><nav><a>About</a></nav></nav>。这种嵌套错误在预览中可能暂时渲染正常，但一旦接入 SSR 或静态生成，就会在构建阶段报错中断。
实操建议：
- 禁用“允许任意区域编辑”权限，按模块划分编辑区（如
<header></header>归前端组长，<main></main>按页面拆分） - 在
index.html顶部加注释块：<!-- EDITOR_LOCK: header -->，作为人工协调信号 - 每日同步前强制运行
npx html-validate --rules "no-invalid-interactive" src/index.html - 不依赖平台自带的“冲突解决提示”，每次协同结束后手动执行
prettier --write并 diff 查看结构变化
真正卡住团队节奏的，从来不是工具选型，而是那些没写进文档、没跑进 CI、也没人在 Code Review 里点破的“默认行为”——比如谁有权删 <h1></h1>，比如 data-* 属性要不要加类型前缀，比如空 <div> 是否允许存在。这些细节不钉死，自动化再强也兜不住人为偏差。</div>
