document.getelementbyid在diff前就失效了，因id重复导致只返回首个节点，使第三方库初始化失败、appendchild错位、屏幕阅读器聚焦错误，且lighthouse报“duplicate id”，而react/vue的key与html id无关，无法规避此问题。
document.getElementById 在 diff 前就失效了
现代框架（React、Vue）的 diff 算法本身不依赖 document.getElementById，但很多开发者会在组件挂载后手动调用它来绑定第三方库、初始化富文本编辑器或做无障碍增强——一旦 ID 重复，document.getElementById('editor') 永远只拿到第一个节点，后续实例的 JS 初始化直接跳过，表面渲染正常，实际功能残缺。
更隐蔽的问题是：框架 diff 时假设 DOM 结构稳定，而重复 ID 往往意味着模板复用失控。比如 Vue 的 v-for 中写 <div id="item">，5 个元素生成后，<code>document.getElementById('item') 返回的始终是第一个。若你在 mounted 里靠它找容器再 appendChild 插入子内容，所有后续项都会被塞进同一个 DOM 位置。
React/Vue 的 key 和 id 不是一回事
React 的 key 是虚拟 DOM 层的标识，仅用于 diff 时判断节点复用逻辑；HTML 的 id 是真实 DOM 的全局唯一锚点，两者完全解耦。把 key={item.id} 当成 id={`item-${item.id}`} 直接用，看似省事，实则埋雷：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 服务端渲染（SSR）时若 key 相同但上下文不同（如两个列表共用同一组 item.id），hydration 阶段可能把事件监听器挂错位置
-
id被用于label[for]或aria-labelledby时，重复会导致屏幕阅读器聚焦错误输入框 - Lighthouse 会直接报 “Duplicate ID”，影响可访问性评分，且无法通过 React 的 key 规避
diff 算法真正在意的是结构一致性，不是 ID 唯一性
React 的 reconciler 看的是 fiber 树的 type、key、props.children 是否变化，根本不会读取真实 DOM 的 id 属性。但 ID 冲突会破坏你对 DOM 的控制权：
- 使用
useEffect+document.getElementById获取节点时，返回值不可靠 - 用
querySelectorAll('[id="submit"]')替代，能拿到全部，但需手动遍历——这和框架设计的“声明式”初衷相悖 - 微前端场景下，子应用注入含重复 ID 的 HTML 片段，主应用的
getElementById可能突然返回子应用里的节点，而非预期主应用节点
真正危险的不是 diff 出错，而是你写的“胶水代码”在 ID 冲突下静默失效，且控制台几乎不报错——只有用户点击提交按钮没反应、语音导航跳过字段、Lighthouse 报告里躺着一个被忽略的 “Duplicate ID” 条目。
