getElementById() 返回 null 的根本原因有两个：DOM 未加载完成或 id 不匹配（大小写错误、非法字符、重复定义）；需确保脚本置于 </body> 前或监听 DOMContentLoaded，并始终检查返回值。
HTML 元素的 id 是 JavaScript 定位它的最直接凭证，但不是所有带 id 的元素都能被 document.getElementById() 立即取到——时机和唯一性是两个最容易翻车的地方。
为什么 getElementById() 返回 null？
这是最常遇到的问题，根本原因就两个：
- DOM 尚未加载完成，脚本执行时目标元素还没解析到页面上（尤其当
<script>放在<head>里） -
id值不匹配：大小写错误、多空格、含非法字符（如my-id合法，但某些旧 IE 对连字符敏感）、或重复定义（HTML 规范要求id必须唯一，但浏览器不会报错，getElementById()只返回第一个）
验证方法很简单：console.log(document.getElementById('xxx')) —— 如果输出 null，先检查控制台是否报错，再确认元素是否已存在、id 是否拼对。
id 命名有哪些实际限制？
虽然 HTML5 放宽了 id 的字符范围，但为兼容性和可维护性，建议坚持以下规则：
立即学习“Java免费学习笔记（深入）”；
- 只用字母、数字、下划线
_、短横线-，且必须以字母开头（避免id="123btn"这类写法） - 不要用纯数字（如
id="123"），某些浏览器解析会出问题 - 避开 JavaScript 保留字（如
id="class"或id="for"），虽不报错，但可能干扰调试工具或框架识别 - 大小写敏感：HTML 中写
id="MyBtn"，JS 里必须用getElementById('MyBtn')，不能写成'mybtn'
如何确保元素一定取得到？
关键不在函数本身，而在调用时机和防御性写法：
- 把脚本放在
</body>前，或用DOMContentLoaded事件包裹：document.addEventListener('DOMContentLoaded', () => { const btn = document.getElementById('submit-btn'); if (btn) btn.addEventListener('click', handler); }); - 永远检查返回值：
if (!element) { console.warn('Element #xxx not found'); return; } - 不用
id也能通信？可以，但更重：用data-*属性 +querySelector()更灵活，比如document.querySelector('[data-role="save-button"]')，适合组件化场景
现代替代方案要不要考虑？
getElementById() 依然高效、语义清晰，没有理由弃用。但要注意：
- 它只返回单个元素；如果需要多个同名逻辑的节点，改用
getElementsByClassName()或querySelectorAll()更合适 - Vite / Webpack 等构建工具中，若开启 HTML 压缩，某些插件可能误删空
id或优化掉未使用的id，导致运行时报null—— 开发环境务必关掉压缩来排查 - SSR（服务端渲染）场景下，首次 JS 执行时 DOM 已存在，但 hydration 阶段若组件 ID 动态生成，前后端不一致会导致取不到元素 —— 此时应用
useEffect（React）或onMounted（Vue）等生命周期钩子延迟获取
真正容易被忽略的，是跨框架场景下的 ID 冲突：比如 Vue 组件模板里写了 id="modal"，又在全局 JS 里用 getElementById('modal')，一旦多个实例挂载，ID 就不再唯一 —— 这时候别硬刚 id，改用 ref 或事件总线更稳妥。
