DOM核心操作与C/C++开发环境五步部署

刚看到这个标题的时候我笑了——前半截是「C C++最全JS基础8-DOM(1)」，后半截是「五步搞定C C++开发环境部署」，一个标题硬塞了两条完全不相干的技术线。但笑着笑着又觉得挺真实：很多从 C/C++ 出身、后来要写页面的人，脑子里就是这么一副拼图——手上一边敲着g++ hello.cpp，一边在浏览器的 DevTools 里翻 DOM 树。我给一个跨端工具写本地能力的时候就是这样，白天调 C++ 编译链，晚上对着 DOM 节点改交互。所以这篇不打算假装自己是一份「系列教程第 8 篇」，而是把这两件事一次说清楚：一是 JS 基础里最容易被跳过、又最决定手感的那块——DOM 到底是什么、怎么高效地查改增删、事件怎么布；二是C/C++ 开发环境的五步落地，装完就能编译、能断点、能管多文件工程。适合刚接触前端想补基础的、也适合写 C/C++ 顺手要做点页面交互的，零基础能照着抄，有基础的能挑着看细节。

1. 先把标题拆开看：DOM 和 C/C++ 环境为什么总被凑在一起

1.1 一个标题里塞两件事，其实是两类人的共同处境

标题的混搭不是笔误，它映射的是一种很常见的技能组合结构。写 C/C++ 的人往往要产出「工具」而不是「网站」：命令行程序、本地服务、给编辑器做插件、做跨端应用的底层模块。这些工具一旦要给人用，最省事的界面就是网页——丢一个本地页面出去，双击就能开，不用装框架。于是画面变成了：核心逻辑用 C++ 写，交互界面用原生 JS 写，中间靠一层本地通信对接。这种组合下，两边的基本功都得硬，缺一边就卡壳。

反过来说，从一开始学 JS 的人，迟早也会碰到 C/C++ 相关的场景：Node 的原生模块、WebAssembly 的性能热点、构建工具里那些需要本地编译的依赖。你没打算写 C++，但node-gyp报了一屏错，你还是得知道编译器在哪、PATH 有没有配对。所以「JS 的 DOM」和「C/C++ 的环境」并列在一个标题里，虽然字面上乱，逻辑上却是一个人的两条腿。这篇就按这个思路分两半讲，中间不强行缝合，各讲各的干货。

我把顺序定成先 DOM 后环境，理由是 DOM 的概念债欠得越晚越难还。很多人写页面写了半年，仍然分不清children和childNodes、querySelectorAll的结果为什么「不会自动更新」，问题都出在最初的节点模型没建立起来。环境那部分反而好办，五步走完就是熟能生巧，唯一麻烦的是第一次装的时候被各种路径和环境变量绕晕。

1.2 为什么 DOM 要从「节点树」讲起，而不是从 API 讲起

几乎所有速成教程都是这个顺序：先教你document.getElementById，再教你innerHTML，然后让你做一个待办清单。能跑，但没建立模型，后果是后面每一步都在试错。我的建议反过来：先在你的脑子里装一棵树，再去记那些方法名。

浏览器拿到一段 HTML 文本，做的是三件事：词法分析把标签切成记号，语法分析按嵌套关系拼成结构，最后在内存里造出一棵由对象组成的树。这棵树就是 DOM。注意三个关键词：对象、树、内存。是对象，所以每个节点都有属性和方法，你能.出来；是树，所以有父子兄弟关系和遍历路径；在内存里，所以它跟磁盘上那份 HTML 文件早就没关系了——你改 DOM，文件一个字都不会变，刷新页面就全没了。这一条是新手最容易误解的地方。

提示：把 DOM 理解成「一份可被程序修改的内存数据结构」，而不是「页面源码的另一种写法」，后面所有关于性能、状态丢失、事件失效的问题都会顺理成章。

树上的节点是有类型的，因为 HTML 里不只有标签。标签是元素节点，标签之间的换行缩进是文本节点，注释是注释节点，整个文档本身是文档节点，还有一类专门用来做批量插入优化的片段节点。这一点非常关键：你写<div>\n <span>hi</span>\n</div>，div的子节点数量不是 1，而是 3——一个换行文本、一个 span、一个换行文本。很多人第一次打印childNodes.length看到 3 就懵了，原因就在这。而children只算元素，结果是 1。这两个属性的差别，是后面所有遍历代码正确与否的分水岭。

顺便说说这个模型为什么这么设计。因为页面是活的：数据变了要改、用户点了要改、动画跑起来每一帧都在改。如果 DOM 只是一个字符串，每次改动都得重新解析整份文档，代价无法接受。用对象树，改动可以精确到某一个节点，浏览器只需要重算受影响的那条分支。这是「为什么 DOM 慢」这个问题的起点——不是 DOM 本身慢，是树上的每一次结构变动都可能触发后续的样式计算和布局。

1.3 这棵树的入口和常用坐标

入口永远是document。它本身是文档节点，向下能拿到documentElement（也就是html元素），再往下是head和body。实际开发中绝大多数查询都从document或某个已拿到的元素出发。

树上有几个「坐标」需要背下来。父节点是parentNode，父元素是parentElement；子节点集合是childNodes，子元素集合是children；第一个子节点firstChild，第一个子元素firstElementChild；最后同理有lastChild和lastElementChild。兄弟方向是nextSibling/previousSibling（含文本节点）和nextElementSibling/previousElementSibling（只算元素）。

我的经验是：除非你明确要处理文本节点和注释，否则一律用带 Element 的那一套。写firstChild然后在调试器里看到一个#text节点，是新手最常见的低级卡点，而且它跟 HTML 里的换行方式有关——你把模板压缩成一行，代码又对了，这种 bug 特别折磨人。

2. DOM 的骨架：节点判断、选择器与集合的坑

2.1 nodeType 判断与 nodeName 的真实取值

节点类型用一个数字表示，存在nodeType属性上。最常用的几个：1 是元素，2 是属性（历史遗留，基本不用），3 是文本，8 是注释，9 是文档，11 是文档片段。写工具函数的时候，用数字比用字符串快，但可读性差，所以我一般在项目里建个常量表，或者直接写一个isElement(node)的小封装。

// 常见节点类型速查 const NODE = { ELEMENT: 1, TEXT: 3, COMMENT: 8, DOCUMENT: 9, FRAGMENT: 11, }; function isElement(node) { return !!node && node.nodeType === NODE.ELEMENT; }

nodeName有个容易翻车的细节：在 HTML 文档里，元素的nodeName是大写的标签名，比如div元素返回'DIV'；而文本节点的nodeName固定是'#text'，注释是'#comment'，文档是'#document'。这就导致你可能想用nodeName === 'div'判断，结果永远不成立。稳妥写法是统一转小写再用tagName，或者干脆用nodeType加localName。

localName返回小写的标签名，对带命名空间的文档（比如 SVG）也更可靠——SVG 里元素的nodeName大小写行为跟 HTML 不一样，写通用代码时localName是更安全的选择。这类细节平时用不上，一旦你要处理内联 SVG 图标，就会立刻用到。

注意：判断「是不是某个标签」时不要依赖nodeName的大小写。用localName或者tagName.toLowerCase()，一次写对，省掉以后排查半小时。

2.2 querySelector 和 getElementById 到底该用哪个

这个问题被问过无数遍，答案不是「哪个更好」，而是「看场景」。

getElementById是唯一一个按 id 直接命中的方法。浏览器在构建 DOM 的时候会维护 id 的索引，所以它是常数级查找，速度最快，而且返回的必然是单个元素或null。缺点是只能按 id，而 id 在页面里必须唯一，滥用 id 做样式钩子会让结构变脆。

querySelector接受任意合法的 CSS 选择器，返回第一个匹配元素。它的代价是每次调用都要解析选择器字符串，复杂选择器（多层后代、属性组合、伪类）还有额外的匹配开销。querySelectorAll同理，但返回全部结果。

我的选择标准很简单：能用 id 定位的用 getElementById；需要按结构、属性、状态定位的用 querySelector；一次要拿一批同类的用 querySelectorAll。另外有个反直觉的点：querySelectorAll在现代浏览器里对简单选择器的优化已经很好，在几百个节点的量级上，它和getElementsByClassName的差距根本不构成性能瓶颈。别为了想象中的性能去用活集合，然后被「循环里删除元素跳项」这个坑绊倒——这是本末倒置。

还有一个细节值得知道：getElementById只挂在document上，元素节点没有这个方法；querySelector每个元素都有，作用域被限制在该元素的子树内。所以想在某个容器里找，直接用容器调querySelector，比先全局找再过滤干净得多。

2.3 活集合与静态集合：一个集合引发的血案

这是 DOM 入门里第二大的坑（第一大是children和childNodes）。getElementsByClassName、getElementsByTagName、children返回的是HTMLCollection，它是活的：DOM 一变，它自动更新。querySelectorAll返回的是NodeList，它是静态的：拿到那一刻拍了张快照，后面 DOM 怎么变它都不动。

看一段经典翻车代码：

// 错误示范：活集合边遍历边删除，会跳项 const items = document.getElementsByClassName('item'); for (let i = 0; i < items.length; i++) { items[i].remove(); }

因为items是活的，删掉第 0 个之后，原来的第 1 个变成了第 0 个，而i已经加到 1，于是跳过了一个。改法有三种：倒着遍历、先转成数组Array.from(items)、或者干脆用静态的querySelectorAll。

// 正确写法之一：先快照再操作 const items = document.querySelectorAll('.item'); items.forEach((el) => el.remove());

注意这里querySelectorAll返回的静态NodeList有forEach方法，而活的HTMLCollection没有——它只有length和下标访问，想遍历得借Array.from或者for...of（HTMLCollection是可迭代的，这点容易记混）。所以我一般建议：默认用querySelectorAll，除非你需要「自动感知新增元素」这种活集合的特性，而这种需求其实用 MutationObserver 或事件委托更合适。

3. 增删改查：DOM 操作的四个动作与真实开销

3.1 创建与插入：为什么要先攒进文档片段

创建元素用document.createElement('div')，然后往里面塞内容。塞内容有两条路：textContent和innerHTML。前者只当纯文本处理，标签会被原样显示；后者会把字符串当 HTML 解析。安全上的差别巨大：如果字符串来自用户输入，innerHTML就是注入漏洞，textContent则完全安全。我的习惯是默认textContent，只有在内容确实是我自己控制的静态模板时才用innerHTML。

插入的方法有一堆：appendChild一次一个节点，append可以同时接受多个节点和字符串，prepend插到最前面，before/after插到兄弟位置，replaceWith替换自身。新手记不住，我给一个记忆锚点：带 Element 后缀的是老 API 只能插节点，没有后缀的（append、prepend、before、after）是新 API 能插字符串。

批量插入是最能体现基本功的地方。如果循环里每次都appendChild，每次都会触发一次结构变更，浏览器要重新计算样式和布局，几百次累加起来就是肉眼可见的卡顿。标准做法是先把所有节点挂到一个游离的文档片段上，最后一次挂进真实 DOM：

const frag = document.createDocumentFragment(); for (const item of dataList) { const li = document.createElement('li'); li.textContent = item.title; li.dataset.id = item.id; frag.appendChild(li); } listEl.appendChild(frag); // 只触发一次

DocumentFragment在内存里存在，但不在文档树上，所以对它做任何操作都不会引起重排。这个技巧没有任何代价，属于「知道了就一定要用」的那一类。顺带说，如果只是往已有容器里追加一大段 HTML 字符串，insertAdjacentHTML比innerHTML +=快得多——后者会把容器里原有的子树整个解析重建，已绑定的事件监听器全部丢失。这个坑我在早期的项目里踩过，列表点不动了查了半小时，原因就是某处图省事写了innerHTML +=。

3.2 改属性与样式：attribute、property、class 三条路

改一个元素的「属性」在 DOM 里其实是两套系统，必须分清楚。

第一套是特性（attribute），用getAttribute/setAttribute/removeAttribute，操作的是 HTML 上写的那段文本，取出来永远是字符串。第二套是属性（property），直接.访问，比如input.value、a.href、div.className，它返回的是真实类型，也是页面当前的实际状态。

很多属性两者不同步，最典型的例子是value：input.getAttribute('value')拿到的是 HTML 里写死的初始值，而input.value是用户输入后的当前值。你在表单里用了哪个，结果天差地别。再比如href，getAttribute('href')返回你写的相对路径，.href返回解析后的绝对地址。判断「用户改过没有」要用.value，判断「初始配置是什么」可能要用getAttribute。

改类名有三条路：className整体覆盖、classList.add/remove/toggle/contains精确增删、或者setAttribute('class', ...)（基本不用）。选classList，它有toggle的第二个参数可以直接指定力度，写状态切换非常顺手。

// 状态切换的标准写法 tabBtn.classList.toggle('is-active', isActive);

改样式也一样分层：.style.width = '200px'改的是内联样式，优先级高、会覆盖样式表，但只适合动态计算的场景；靠切换类名改样式则是主流做法，样式和逻辑分离，还好维护。如果只是「当前是否需要生效」，用类名；如果是「宽度等于从数据算出来的数字」，用内联。.style的属性名要用驼峰（backgroundColor），而setProperty用连字符（background-color），两者别混。

读最终计算样式要用getComputedStyle(el)，它返回的是浏览器算完之后的值，包含样式表里来的、继承来的、默认值。注意它返回的是只读快照，改它不会生效；而且每次调用都可能强制浏览器把样式算一遍，别放在循环里反复调。

注意：el.style.width只能读到内联样式。你在 CSS 里写了.box { width: 200px }，.box 元素.style.width返回空字符串。想拿到200px，必须用getComputedStyle。

3.3 删除、替换与「先摘下来再装回去」

删除有el.remove()（新，简洁，直接删自己）和parent.removeChild(el)（老，需要父节点引用）。替换用oldEl.replaceWith(newEl)或parent.replaceChild(newEl, oldEl)。手册上还有innerHTML = ''这招清空容器，它确实快，但会把子树连同事件监听一起销毁——如果你的监听是绑在子元素上的，清空后重建的节点是新的，监听不在了。

这里引出一个非常实用的经验：批量修改一个已有容器之前，先把容器从文档流里摘下来，改完再装回去。因为它脱离文档后，所有改动都不触发布局计算，最后一次挂载只算一次。

const parent = listEl.parentNode; const next = listEl.nextSibling; parent.removeChild(listEl); // 在这里放心地对 listEl 做几十次修改 parent.insertBefore(listEl, next);

注意保存原来的位置，insertBefore时把nextSibling传回去，才能回到原位；如果它是最后一个子节点，nextSibling是null，此时insertBefore(el, null)等价于appendChild，逻辑正好自洽。

还有一个需要知道的现象：把一个已在文档中的节点appendChild到别处，它不是复制，而是移动。新位置插进去，老位置自动消失。想做复制得用cloneNode(true)，参数true表示深拷贝子节点。但拷贝出来的节点不携带事件监听（除非用带参数的新版cloneNode特性，兼容性一般），也不保留通过 JS 设置的某些状态，这一点在用模板复制行的时候要留意。

4. 事件：从冒泡到委托，把绑定数量压下来

4.1 事件流的三个阶段和那两个容易混的 target

点击一个按钮，事件其实不是直接到按钮上的。它走三个阶段：从文档根往下捕获，到达目标本身，再从目标往上冒泡回根。默认情况下addEventListener绑的是冒泡阶段，想绑捕获阶段就把第三个参数设成true，或者写成{ capture: true }更清楚。

回调里有三个关键信息。event.target是真正被点到的那个元素，可能是按钮里的图标；event.currentTarget是当前绑定监听的那个元素，在回调执行期间它和this相等（箭头函数没有自己的this，所以用箭头函数时只能靠currentTarget）。很多人用委托时拿target去判断类名，结果点到子元素就失效，原因就在于没分清这两个。

第三个参数还有个对象写法，能带两个很实用的开关：once让监听只触发一次，用完自动解绑，特别适合「只初始化一次」的场景；passive告诉浏览器「这个回调里不会阻止默认行为」，浏览器就能放心地先滚动再执行，滚动性能会明显改善。

window.addEventListener('scroll', onScroll, { passive: true }); // 这个回调里调用 preventDefault() 会被忽略，控制台会警告

passive用在touchstart、touchmove、wheel、scroll上是收益最大的，因为这些事件一旦被阻止，浏览器就得等回调跑完才能决定要不要滚，用户感觉到的是「页面跟手变差」。

4.2 事件委托的实操模板和它的边界

列表里 500 行，每行一个删除按钮，如果挨个绑监听就是 500 个函数对象。委托的做法是：只在列表容器上绑一次，通过target往上找最近的按钮，再定位到行。

listEl.addEventListener('click', (e) => { const btn = e.target.closest('[data-action="remove"]'); if (!btn || !listEl.contains(btn)) return; const row = btn.closest('[data-id]'); if (!row) return; removeItem(row.dataset.id); row.remove(); });

这段代码有几个讲究。closest从自身开始向上匹配选择器，比自己写 while 循环爬 parentNode 清爽得多，而且点中按钮里的 svg 图标也能正确找到按钮。contains那层判断是防御性的，防止某些节点被移动之后closest爬到了容器外面。用>let ticking = false; window.addEventListener('scroll', () => { if (ticking) return; ticking = true; requestAnimationFrame(() => { const top = document.documentElement.scrollTop; // 读 header.classList.toggle('is-stuck', top > 80); // 写 ticking = false; }); }, { passive: true });

第二个层面更隐蔽：在同一帧里交替读和写几何属性，会强制浏览器反复布局，这叫布局抖动。上面的代码之所以先读scrollTop再写类名，就是为了把它们放在同一次任务里，读一次、写一次。一旦你在循环里写一个元素、读下一个元素的offsetHeight，每一次读都会触发一次同步布局，节点一多直接卡死。这个坑不看现象很难发现，因为它不报错，只是慢。

5. 五步搭好 C/C++ 开发环境：从能编译到能调试

5.1 第一步与第二步：定编译器，再装工具链

环境部署最容易走的弯路是顺序反了：先装编辑器，装完发现编辑器找不到编译器，又到处搜插件配置，越配越乱。正确的顺序是先保证命令行能编译，再去配编辑器。命令行通了，编辑器只是调用它而已。

第一步是确定编译器家族。三大主流：GCC（Linux 上是标配）、Clang（macOS 上是标配，错误提示更友好）、MSVC（Windows 上的原生方案）。选择依据不是「哪个更强」，而是「你手头系统上哪个最省事」：Linux 直接gcc/g++；macOS 装命令行工具后clang++就在；Windows 上最轻的路子是 MinGW-w64 这一套，能提供g++，跟 Linux 上的命令保持一致，跨平台教程可以直接抄。

第二步是真正安装。Linux 上一条命令搞定构建工具集，Debian 系大致是sudo apt install build-essential，它会带上编译器、链接器和 make。macOS 上执行xcode-select --install，弹窗确认后等它装完，clang++ --version有输出就成了。Windows 上装 MinGW-w64 的发行版，安装时有一个关键选择：架构选x86_64，线程模型选posix（对 C++ 标准库支持更完整），异常模型选seh（性能和兼容性平衡最好）。这三项装错了，后面遇到的会是莫名其妙的运行期崩溃，很难往安装选项上联想。

安装路径也有讲究：不要放在带空格或中文的目录里。C:\Program Files\...这种路径会让一部分构建脚本在传参时被截断，报出「找不到文件」这种看着毫不相干的错误。直接放C:\dev\mingw64之类，路径短、无空格、纯英文，能省掉一整类问题。

5.2 第三步：PATH 配对，然后在命令行里验证

装完还没结束，必须让系统在任何目录下都能找到编译器，这就靠 PATH。Windows 上要把C:\dev\mingw64\bin加进系统环境变量 PATH（注意是bin目录，不是安装根目录）；Linux / macOS 一般安装器会自动处理，如果用的自己的目录，就在 shell 配置文件里追加一行export PATH=/your/path/bin:$PATH，然后重新开一个终端让配置生效。

验证分三步，缺一不可：

g++ --version # 看版本号，确认能找到 where g++ # Windows 用这条，看实际命中的路径 which g++ # Linux / macOS 用这条

第二条命令是很多人忽略的。如果机器上装了两套编译器（比如装过某个带编译器的开发包），g++ --version能输出但版本不对，where才会告诉你实际用的是哪一个。PATH 的顺序决定优先级，前面那个目录胜出。这个坑的典型症状是：明明新装的是新版，编译报错却还是旧版的行为。

验证完就把第一个程序跑通：

g++ hello.cpp -o hello -std=c++17 -Wall -Wextra -g ./hello # Windows 上是 hello.exe

这里每个参数都有理由。-std=c++17显式指定标准，不指定的话不同编译器默认标准不一样，同一份代码在别人机器上可能编不过；-Wall -Wextra打开常用警告，很多未定义行为的早期信号就藏在这些警告里，别嫌吵；-g生成调试信息，没有它后面的断点根本打不中；-o指定输出名，建议放前面，虽然放后面也行，但位置统一了脚本更好改。

注意：源文件是.c后缀时用gcc编译，.cpp用g++。用g++编.c文件会按 C++ 规则处理，某些写法会突然报错。反过来用gcc编 C++ 文件，会在链接阶段报一堆undefined reference，因为它不自动链接 C++ 标准库。

5.3 第四步：编辑器的智能提示和调试配置

命令行通了，再配编辑器。这一步的核心是三份配置，弄明白它们各自管什么就不会乱：一份管去哪找头文件（供智能提示用），一份管怎么编译（任务），一份管怎么启动调试（调试器配置）。很多现代编辑器插件能自动探测，但一旦你用了非标准路径，就得手动补。

要补的关键路径是编译器的头文件目录，通常形如<安装目录>/include和<安装目录>/lib/gcc/.../include。配上之后，#include <vector>下面就不会有红波浪线，Ctrl+点击能跳进标准库源码，这对读源码帮助极大。

调试配置有两个硬性要求：编译时必须带-g，且调试时不要开-O2。开了优化，编译器会重排语句、内联函数、复用变量，断点跳来跳去、变量显示「已被优化掉」，新手会以为自己的代码有诡异问题。我一般准备两套编译参数：日常调试用-g -O0，出成品用-O2 -DNDEBUG，互不干扰。

还有一个跨平台的小差别值得记住：Linux 上常用gdb，macOS 上得用lldb，Windows 的 MinGW 环境里也是gdb。断点、单步、查看调用栈这些操作逻辑都一样，只是命令拼写不同，别在 mac 上敲gdb然后怀疑人生。

5.4 第五步：从单文件命令到 CMake 工程

单文件阶段g++ a.cpp -o a就够了，一到多文件就必须换思路。三个源文件互相#include，手写 g++ 命令会变成一长串，加一个文件改一次，改错一次就报链接错误。这时候该上构建系统了。

最朴素的替代方案是自己写一个Makefile或者一个 shell 脚本，把所有源文件列出来一起编：

g++ src/main.cpp src/util.cpp src/log.cpp -Iinclude -o app -std=c++17

-Iinclude是告诉编译器额外去include目录找头文件，这是多文件工程第一次必须打交道的东西。如果后面要用第三方库，还会有-L（库目录）和-l（具体库名），注意-l后面跟的库名要去掉lib前缀和扩展名。

工程再大一点，直接上 CMake。它不直接编译，而是根据一份描述生成对应平台的构建文件，这样同一份工程在三个系统上都能用。最小可用版本长这样：

cmake_minimum_required(VERSION 3.16) project(demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) add_executable(app src/main.cpp src/util.cpp src/log.cpp ) target_include_directories(app PRIVATE include)

几个点解释一下。CMAKE_CXX_STANDARD_REQUIRED ON表示不支持指定标准就报错，而不是悄悄退回旧标准——这个开关能提前暴露「我的编译器太老」这个问题。CMAKE_CXX_EXTENSIONS OFF关掉编译器私有扩展，代码可移植性更好。target_include_directories是给具体目标设头文件目录，比全局的include_directories精确，也更好维护。

流程是：建一个build目录，进去跑cmake ..生成构建文件，再跑cmake --build .编译。单独建目录的意义是「源码目录保持干净」，编译产物全在build里，删掉这个目录就等于彻底清理，不会留下莫名其妙的中间文件。这个习惯在跨平台项目里几乎是刚需。

6. 踩坑实录：两边的高频故障与速查表

6.1 DOM 侧：那些不报错但就是不生效的问题

第一类问题：明明改了样式，页面没反应。排查顺序是——元素找对了吗（console.log打一下，是不是null）；样式写的是内联还是类名，有没有被更高优先级盖掉（看计算样式里那条是否被划掉）；.style.width = 200忘了带单位，赋值直接无效且不报错。第三条最阴，因为不报任何错。

第二类：事件绑了但点不动。常见原因有四个——元素在绑定时还不存在（脚本放在了元素前面，或者节点是后插入的），用委托可以规避；绑在document上但回调里return早了；被父级的stopPropagation拦了；绑在了会被替换掉的节点上（innerHTML重建过）。

第三类：列表操作之后事件全失效。基本可以断定是用了innerHTML +=或者整块重建，旧的监听随旧节点一起释放了。改法有两种：用事件委托，让容器统一处理，重建多少次都不怕；或者重建完成后重新绑。我强烈推荐前者，因为后者会在代码某处漏一句，然后变成偶发 bug。

第四类：querySelectorAll拿到的集合循环里删元素没删干净。原因同上文的静态/活集合差别，静态集合其实不会有这个问题，一般是混用了getElementsByClassName。

第五类：脚本时报Cannot read properties of null。九成是执行时机早于节点解析。把脚本放body末尾、加defer、或者包在DOMContentLoaded里，三种方式任选。这里顺便区分一下：DOMContentLoaded在文档结构解析完就触发，不等图片和样式；load要等所有资源加载完，慢得多。需要尽早操作的用前者。

6.2 环境侧：编译能过但链接不过是怎么回事

「编译错误」和「链接错误」是两类完全不同的问题，分清楚能节省大量时间。编译错误发生在单个源文件翻译阶段，报的是语法、类型、头文件找不到，通常带行号和列号。链接错误发生在所有.o汇总成可执行文件阶段，典型症状是undefined reference to ...，只报符号名，没有行号。

undefined reference的三大来源：函数只声明没定义（写在头文件里忘了实现）；对应的源文件没参与编译；用了外部库但没加-l。想快速定位，就把完整命令打出来看有没有漏文件，或者用nm查符号在不在目标文件里。

No such file or directory出现在#include上，就是头文件路径没给对，检查-I有没有加、路径是相对当前的哪一级。注意相对路径的基准是「你执行编译命令时所在的目录」，不是你源文件所在的目录，这一点坑过无数人。

编码问题也常见。Windows 控制台默认代码页跟 UTF-8 源文件不匹配，输出中文变乱码。解决方向是编译时指定执行字符集，或者让终端切到 UTF-8。还有一种情况是文件真实编码是 GBK 但编辑器按 UTF-8 打开了，显示正常但编译报错，那就用编辑器的「以指定编码重新打开」功能确认一下。

调试打不上断点，一般三个原因：没带-g；开了优化；调试器加载的可执行文件跟你以为的不是同一个（build目录里有一堆同名产物时很容易发生）。确认方法很简单，在调试控制台里打印一下当前加载的可执行文件路径。

6.3 高频问题速查表

6.4 两条我自己踩出来的经验

第一条关于 DOM：先写「读」，再写「写」，中间不要来回切。任何一次涉及几何信息的批量操作，我现在的习惯是把所有要读的值先收集到一个数组里，再统一写回去。这个改法看起来麻烦，但解决过一次列表滚动卡顿之后，我就再没写过读写交替的循环。

第二条关于环境：环境出问题时，先退回到最小可复现状态。写一个只有三行的hello.cpp，用最长的那条g++命令编译，能过就说明工具链没问题，问题在你自己的工程；不能过就说明是环境本身的问题，别在工程配置上瞎改。这个二分法能省掉大量「到底是我代码错还是环境错」的摇摆时间。

写到这里，两边的东西其实都交代完了。我个人的体会是，DOM 那部分的难点从来不是 API 记不住，而是没有建立起「这是一棵内存里的活树、每次结构变动都有成本」的意识；环境那部分的难点也不是步骤多，而是顺序错、路径脏、两个编译器打架。这两件事的共同点是，网上搜到的答案大多只给结论，不给推理过程，于是每次遇到相似问题都得重搜一遍。把推理过程补上，才是真的学会了。