DOM操作是JavaScript与网页交互的唯一入口；document.getElementById因兼容性好、性能优、语义明确仍为查ID首选；innerHTML解析HTML但有XSS风险，textContent仅处理纯文本且更安全高效；应避免内联事件，优先用addEventListener；真正难点在于依据浏览器机制和框架生命周期决策何时操作DOM。
DOM操作是JavaScript与网页交互的唯一入口——没有它，脚本就只是静态代码，无法响应点击、更新内容、验证表单或动态加载数据。
为什么document.getElementById仍是首选？
它兼容性最好（IE6+），性能最快，且语义明确：只找一个元素，返回null或Element。现代开发中仍大量用于初始化关键节点（如#app、#header）。
- 别用
document.querySelector替代它来查ID——语法更长、性能略低、错误时返回null但不易定位问题 - ID必须全局唯一；若重复，
getElementById只返回第一个匹配项，不报错也不警告 - 它不支持CSS伪类（如
:hover）或复杂选择器，这反而是优势：边界清晰，行为可预测
innerHTML vs textContent：该用哪个？
二者都改内容，但安全性和用途截然不同。
-
innerHTML会解析HTML字符串，适合渲染富文本、组件模板或服务端返回的片段；但直接插入用户输入极易引发XSS，必须先转义或用DOMPurify -
textContent只当纯文本处理，自动转义所有标签，适合填入用户名、错误提示、搜索关键词等不可信内容 - 性能上，
textContent更快（无解析开销），且不会触发内联事件重绑定或资源重新加载（如）
事件绑定为何要避免onclick属性写法？
内联事件（如）把逻辑耦合进HTML，破坏关注点分离，且无法动态移除或批量管理。
- 用
addEventListener可多次绑定同一事件，支持选项（如{ once: true, passive: true }），还能精确控制捕获/冒泡阶段 - 内联写法中的
this指向window而非元素本身，容易引发隐式错误 - 服务端渲染（SSR）后，内联事件在hydrate阶段无法被React/Vue等框架接管，导致交互失效
真正难的不是调用哪个API，而是判断“此刻该不该操作DOM”——比如列表渲染是否该用innerHTML拼接，还是走createElement + appendChild；又比如事件委托该挂载到body
