JavaScript操作DOM的核心是精准获取与安全修改元素：用querySelector/querySelectorAll按CSS选择器查找，注意语法、时机和返回类型；修改内容优先选textContent（安全）或innerHTML（解析HTML），慎用innerText；ID查找用getElementById（性能高、语义明）；改样式用classList而非style对象，设属性优先直接赋值布尔属性。
JavaScript 操作 HTML 的核心就是操作 DOM，而绝大多数问题其实卡在「找不着元素」或「改了没反应」上。别急着背 API，先确认你用对了方法、选对了时机、改对了属性。
怎样用 document.querySelector 和 document.querySelectorAll 精准获取元素
这两个是现代最常用、也最容易出错的获取方式。它们按 CSS 选择器匹配，但返回结果类型不同：
-
querySelector只返回第一个匹配的元素（null表示没找到），适合唯一目标，比如document.querySelector('#header') -
querySelectorAll返回NodeList（类数组，但不是 Array），要遍历得用forEach或转成数组：Array.from(document.querySelectorAll('.btn')).forEach(...) - 常见错误：写错选择器语法，比如把类名写成
.my-class却漏了点，或 ID 写成#my_id却用了下划线（HTML ID 允许下划线，但 JS 里没问题；真正问题是大小写和拼写） - 注意执行时机：如果脚本在
里且没加defer，DOM 还没加载完，querySelector会返回null
修改内容时，textContent、innerHTML 和 innerText 怎么选
改文字或结构，这三个属性行为差异很大，选错会导致 XSS 风险、样式丢失或性能问题：
-
textContent：只处理纯文本，不解析 HTML，安全、快，适合填用户输入（如表单反馈）；它还会读取隐藏元素的内容 -
innerHTML：解析并渲染 HTML 字符串，功能强但危险——如果插入的是用户数据，必须先转义（或用textContent替代）；它不触发重排，但频繁设置大段 HTML 会慢 -
innerText：受 CSS 影响（比如display: none的内容不计入），会换行缩进，且有兼容性问题（IE 支持，但旧版 Safari 行为不一致），一般少用 - 示例：
el.textContent = 'Hello'显示的就是带尖括号的字符串；而el.innerHTML = 'Hello'才真加粗
为什么 getElementById 还值得用？
虽然 querySelector 更灵活，但 getElementById 在某些场景下不可替代：
立即学习“Java免费学习笔记（深入）”；
- 性能略高（原生 ID 查找，浏览器做了优化），尤其在大量节点中反复查找时能感知到差异
- 返回值永远是 Element 或
null，不用像querySelectorAll那样处理类数组 - ID 必须唯一，所以它语义更明确——你要的就该是那个唯一标识的元素；如果发现多个同 ID，说明 HTML 本身就有问题，不该靠 JS 将就
- 注意：
getElementById参数是字符串 ID 值，不带#，写成document.getElementById('modal')，不是'#modal'
修改样式和属性，别直接碰 style 对象除非必要
直接改 el.style.color = 'red' 看似简单，但容易覆盖其他 CSS 规则，也不利于维护：
- 优先用
el.classList.add('active')、el.classList.toggle('hidden')控制预设样式类，复用性强、可被 CSS 覆盖、支持过渡动画 - 需要动态计算样式时，用
getComputedStyle(el).height读，但不能写；写样式仍走classList或style - 修改 HTML 属性用
el.setAttribute('disabled', '')，但布尔属性（disabled、checked）更推荐直接赋值：el.disabled = true—— 这样更可靠，且与表单控件状态同步 - 避免链式写法如
el.style.width = '100px'; el.style.height = '50px';，可合并为Object.assign(el.style, { width: '100px', height: '50px' })（但注意 vendor prefix 仍需手动加）
DOM 操作真正的复杂点不在 API 多少，而在「什么时候查」「查完有没有」「改了要不要重新绑定事件」「样式类要不要清理」——这些细节不写进代码注释，就很容易在后续迭代中变成幽灵 Bug。