# 退出码是 0，日志没有 ERROR，稿子却没发出去：CDP 脚本里的三种静默失败

那天晚上我要给一个新平台写自动化发布脚本。跑完之后，脚本打印的每一步都像成功：页面打开了、按钮找到了、图片下载了、坐标算出来了、拖动完成了。退出码 0，没有一行 ERROR，没有一次抛异常。

然后我去平台列表里看——那篇文章根本不在。

更糟的是，这不是第一次。同一个晚上，同类型的错误出现了三次，每一次都安静得像成功。我把它们摊开放在一起看，才发现它们其实是同一件事的三个变体：**脚本的每一步都在正常执行，只是执行的结果和你以为的不是一回事。**

## 第一种：返回值取错了一层，于是一切都是空字符串

我写了一个通用的页面探测脚本，用来摸清目标站点上有哪些按钮、哪些输入框。核心就两个函数：`send()` 负责往 Chrome 发 CDP 指令，`ev()` 负责执行一段 JS 并把结果带回来。

```javascript
const send = (method, params) => new Promise((resolve, reject) => {
  const id = ++seq;
  pending.set(id, { resolve, reject });
  ws.send(JSON.stringify({ id, method, params: params || {} }));
});

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);
  if (msg.id && pending.has(msg.id)) {
    const entry = pending.get(msg.id);
    pending.delete(msg.id);
    msg.error ? entry.reject(new Error(JSON.stringify(msg.error)))
              : entry.resolve(msg.result);   // 注意这里：resolve 的是 msg.result
  }
};

const ev = async (expression) => {
  const r = await send('Runtime.evaluate', { expression, returnByValue: true });
  const inner = r.result;
  const boxed = inner.result;
  return (boxed && boxed.value !== undefined)   // 注意这里：多取了一层
    ? String(boxed.value)
    : '';
};
```

看出问题了吗？`send()` 往外抛的是 `msg.result`，也就是 CDP 响应里的 `result` 字段。而 `Runtime.evaluate` 的完整响应长这样：

```json
{ "id": 7, "result": { "result": { "type": "string", "value": "该站首页地址" } } }
```

`msg.result` 已经是 `{ "result": { "type": "string", "value": "..." } }`。所以在 `ev()` 里应该「取 result 再取 value」（两层），我写成了「取 result、再取 result、再取 value」（三层）——**多取了一层**。

多取一层的后果是什么？中间那层 `result` 是 `undefined`，于是整个三元表达式走到 `: ''`，返回一个空字符串。

**一个空字符串。** 不是异常，不是 `null` 引发的 TypeError，不是 reject。就是一个空字符串，安静地流进了后面的每一行代码。

于是我看到的输出是这样的：

```
URL
TITLE
READY
BODYTEXT
INPUTS
```

每一行标签都在，每一个值都是空的。

我当时第一反应是「页面没加载出来」，于是去加等待时间、去检查 CSP、去怀疑是不是附到了错误的标签页。折腾了两轮才想到去打印原始响应：

```javascript
const raw = await send('Runtime.evaluate', { expression: 'location.href', returnByValue: true });
console.error('RAW', JSON.stringify(raw).slice(0, 400));
```

一行就出水了：

```
RAW {"result":{"type":"string","value":"该站首页地址"}}
```

`result.result` 确实存在——它在 `raw` 里面，不在 `raw.result` 里面。

这个 bug 的可怕之处不在于它难修（改一个字符），而在于**它不产生任何信号**。对比一下：

| 错误类型 | 表现 | 你多久能发现 |
|---|---|---|
| 抛异常 | `FATAL Cannot read property 'value' of undefined` | 立刻 |
| reject | `Error: timeout Runtime.evaluate` | 立刻 |
| **返回空** | 一切正常，值为空 | 我用了两轮才反应过来 |

同样是「取值取错了」，如果你取的是 `undefined.xxx`，JavaScript 会当场给你一个 TypeError；但你取的是「对象.字段.子字段」而「对象.字段」恰好存在、「对象.字段.子字段」恰好不存在，你只会得到 `undefined`，然后被我那句防御性的 `: ''` 兜底成了空字符串。**防御性代码把错误信号吃掉了。**

后来我给所有新写的 CDP 脚本定了条规矩：写完 `send()` 和 `ev()`，第一件事是打印一次原始响应确认层级。不是相信自己的记忆，是看一眼。

```javascript
const ev = async (expression) => {
  const r = await send('Runtime.evaluate', { expression, returnByValue: true });
  if (!r) return '';
  if (r.exceptionDetails) {
    const detail = r.exceptionDetails;
    return 'ERR:' + String(detail.text || '');
  }
  const inner = r.result;
  return (inner && inner.value !== undefined) ? String(inner.value) : '';
};
```

顺带说一句：那个 `exceptionDetails` 分支也是这次加的。之前如果 JS 在页面里抛错，中间那层 `result` 不存在，同样会走进 `: ''`——**页面里的异常和取值错误长得一模一样**。现在它们至少能分开。

## 第二种：按钮找到了，点的是它的兄弟

第二个坑出现在「按文字找元素」这件事上。

自动化脚本里最常见的操作是「找到写着『写点什么』的那个东西，点它」。实现通常是遍历所有元素，比对文字：

```javascript
const clickText = async (txt) => {
  const box = await ev(`(function(){
    var want = ${JSON.stringify(txt)};
    var els = Array.from(document.querySelectorAll('div,span,a,button,li'));
    for (var i = 0; i < els.length; i++) {
      var e = els[i];
      var s = (e.textContent || '').trim();
      if (s !== want) continue;        // 精确相等
      var r = e.getBoundingClientRect();
      if (r.width < 6 || r.height < 6) continue;
      return JSON.stringify({ x: Math.round(r.x + r.width / 2),
                              y: Math.round(r.y + r.height / 2) });
    }
    return '{}';
  })()`);
  if (!box || box === '{}') { console.log('NOT_FOUND_' + txt); return null; }
  const p = JSON.parse(box);
  await click(p.x, p.y);
  return p;
};
```

看起来没问题。实际运行时，`clickText('写点什么')` 打印了 `NOT_FOUND_写点什么`。

但那个按钮明明就在页面上——我截图能看到，前面的 DOM dump 也能看到：

```
{"t":"写点什么","tag":"DIV","cls":"write-btn Button_button_3onsJ","x":1148,"y":35}
```

问题出在 `s !== want`。页面上那个元素的 `textContent` 不是 `'写点什么'`，而是 `' 写点什么'`——**前面带了一个字体图标字符**。

这类站点大量使用 iconfont：一个 `<i>` 或者 `<span>` 里放一个私用区字符（比如 ``），靠 web font 渲染成图标。视觉上它是个图标，DOM 里它是个实打实的字符，而且**它属于父元素的 `textContent`**。

所以：

| 你以为的 | 实际的 |
|---|---|
| `'写点什么'` | `' 写点什么'` |
| `'我已阅读并同意协议'` | `'𙜜 我已阅读并同意协议'` |
| `'搜索'` | `''` |

而且这还只是第一层。更难的是，同一个按钮在页面的不同状态下，图标字符还可能不一样——勾选协议前后，那个字符从 `` 变成 `𙜜`。你按「未勾选时的文本」去匹配，勾完就找不到了。

我的第一版修复是放宽匹配：

```javascript
if (s.indexOf(want) < 0) continue;   // 包含匹配
```

这能解决大部分情况，但引入一个新问题：**包含匹配会命中祖先元素**。一个 `<div>` 包着整个按钮区，它的 `textContent` 也包含「写点什么」，而且它在 DOM 里排得更靠前——你会点到一个巨大的容器上，点了个寂寞。

所以完整的写法要同时满足三件事：包含匹配、剥掉不可见字符、优先选最内层元素。现在用的版本是这样：

```javascript
const clean = (s) => (s || '').replace(/[\uE000-\uF8FF\uF0000-\uFFFFD]/g, '')
                              .replace(/\s+/g, ' ').trim();

// 在页面里：
for (var i = 0; i < els.length; i++) {
  var e = els[i];
  var raw = (e.textContent || '').trim();
  var s = clean(raw);
  if (s !== want) continue;
  if (e.childElementCount > 0) continue;   // 只取最内层：没有子元素才可能是文本节点本身
  var r = e.getBoundingClientRect();
  if (r.width < 6 || r.height < 6) continue;
  if (r.y < 0 || r.y > innerHeight || r.x < 0 || r.x > innerWidth) continue;
  return JSON.stringify({ x: Math.round(r.x + r.width / 2),
                          y: Math.round(r.y + r.height / 2) });
}
```

先剥私用区字符（Unicode 的 `U+E000–U+F8FF` 和补充私用区），再做精确匹配。`childElementCount > 0` 这一条保证拿到的是叶子节点——也就是真正承载文字的那个元素，而不是包着它的容器。

这条经验推广出去就是一句很土的话：**你看到的和 DOM 里的不是一回事，尤其是那些你看不见的字符。** 空格、换行、零宽字符、私用区图标字符，都会让 `===` 失效，而它们的共同点是——在渲染结果里完全看不出来。

## 第三种：算法跑完了，答案从一开始就错了

第三个坑是滑块验证码。这次我遇到的站点，滑块长这样：

- 背景图 `img.puzzle`，300×200，**src 是 base64 data URL**
- 拼图块 `img`，52×200，也是 base64
- 拖动把手 `div.slider-move`，40×40

两图都嵌在 DOM 里，省了下载这一步。我复用上一套逻辑：拿拼图块当模板，在背景图上横向滑动，找差异最小的位置——这是标准的模板匹配，之前在另一个站点上成功过。

```python
bg = Image.open('bg.png').convert('RGB')
jg = Image.open('jg.png').convert('RGBA')
alpha = jg.split()[3].point(lambda p: 255 if p > 100 else 0)
tpl = jg.convert('RGB')

results = []
for x in range(0, bw - W + 1):
    win = bg.crop((x, 0, x + W, H))
    diff = ImageChops.difference(win, tpl)
    st = ImageStat.Stat(diff, mask=alpha)
    results.append((sum(st.mean) + sum(st.stddev), x))
results.sort()
```

输出：

```
MATCH {"x":58,"score":152.17,"second":59}
DRAGGED 59
AFTER {"sliderGone":false,"hasTip":true,"sent":false}
SLIDE_FAIL_RETRY
```

拖了 59 像素，滑块没过。

注意这里的信号特征：**没有报错，没有异常，算法完整跑完，还给出了一个看起来非常合理的答案——x=58。** 如果它崩了，我立刻就知道去修；它给了一个数字，我就去用了。

问题出在对滑块类型的假设上。拼图滑块其实有两种：

**内容型**：背景图上的缺口处，显示的是「被抠掉的那块」模糊后的痕迹，而给你的拼图块是**从原图上抠下来的真实像素**。这种情况下，拼图块和缺口位置的内容高度相关，模板匹配很准。

**轮廓型**：背景图上根本没有内容缺失——缺口是一个**白色高亮的拼图形状**叠在上面，而给你的拼图块本身是不透明的纯色（或半透明灰）。

我这次遇到的是后者。验证方法很简单，直接统计拼图块的颜色：

```python
px = jg.convert('RGB')
white = 0; total = 0
for y in range(0, h, 5):
    for x in range(0, w, 5):
        if alpha.getpixel((x, y)) > 100:
            total += 1
            r, g, b = px.getpixel((x, y))
            if r > 220 and g > 220 and b > 220:
                white += 1
print(white, '/', total)
```

输出 `0 / 76`——**76 个采样点里，0 个是白色**。拼图块不是白的，而背景图上的缺口是白的。拿一个「非白的东西」去匹配「白色的区域」，模板匹配当然算不出东西，它只是尽职尽责地在一堆都不像的答案里，挑了一个最不像的：x=58。

正确做法是换个问法：别找「拼图块该去哪」，直接找「背景图上那个白色的形状在哪」。

```python
colcnt = []
for x in range(W):
    c = 0
    for y in range(H):
        r, g, b = px[x, y]
        if r > 205 and g > 205 and b > 205:
            c += 1
    colcnt.append(c)
```

统计每一列的高亮像素数，然后找宽度在 25–70 像素之间的连续高亮区间。实测下来，高亮列集中在 x≈200–220 这个区间（阈值 205 时每列有 40+ 个高亮像素），缺口中心大约在 211。

**58 和 211。** 差了 153 像素。这两个数字都能让脚本「正常运行到最后一步」，只有一个能过验证。

这个坑给我最大的提醒是：**算法的可信度取决于你验证过它的假设，而不是它跑通了几次。** 同一套模板匹配代码在 A 站点成功过三次，不代表它在 B 站点有效——它只代表 A 站点的滑块是内容型。换一个站点，第一件事应该是重新确认「这个滑块的缺口是怎么画出来的」，而不是直接复用。

验证的成本很低（读一下拼图块的像素统计），不验证的成本是：拖一次，失败，刷新，再拖一次，失败——每次失败都要重新走一遍填表、发码、弹窗的完整流程。

## 把三种失败放在一起看

| | 表面信号 | 真实原因 | 为什么没被发现 |
|---|---|---|---|
| 层级取错 | 值为空字符串 | 三层取值 vs 两层取值 | 防御性兜底 `\|\| ''` 吃掉了信号 |
| 文本不匹配 | `NOT_FOUND_写点什么` | textContent 带私用区图标字符 | 页面上根本看不见那些字符 |
| 算法假设错 | 给出 x=58 | 滑块是轮廓型不是内容型 | 算法不会告诉你它的前提不成立 |

三件事有一个共同结构：**每一步都执行了，每一步都「成功」了，但组成起来的结果全是错的。** 而且它们都不会产生异常——因为从程序自己的视角看，它确实每一步都做完了。

这正是我之前在另一篇文章里写过的那件事的延伸：**弱判据的问题不是它经常错，是它错了你不知道。** 那篇讲的是「用页面上的提示文字当判据，结果抓到了自己稿子正文里引用的提示」。这次三个坑是同一件事在操作层的版本——你的判据不是「页面上有没有出现成功提示」，而是「脚本有没有报错」。而脚本报错，从来不等于事情办成了。

## 现在我的做法

三条，都写进了脚本模板：

**1. 新脚本先打印一次原始响应。** 不管是 CDP 返回值、接口 JSON 还是算法输出，第一次接入时打印一次完整结构，确认层级和字段名。成本是十秒钟，收益是避免两轮的瞎猜。

**2. 匹配文本前先归一化。** 剥私用区字符、折叠空白、优先叶子节点。并且对「找不到」这种结果保持警惕——找不到往往不是元素不存在，是你找的方式不对。

**3. 每一步都要有独立于「没报错」的判据。** 拖完滑块，判据不是「拖动指令发出去了」，是「滑块面板消失了」；填完表单，判据不是「insertText 返回成功」，是「输入框的 value 长度等于预期」；发布完，判据不是「脚本退出码 0」，是「文章列表里多了一条，标题对得上」。

最后一条最关键，也最容易被跳过。因为「退出码 0 + 无异常」是一个**太容易达成的状态**——它只要求你的代码没有崩溃，完全不要求你的代码做对了事。

写完这几条之后我重跑了一遍，滑块那部分还是没过（后来是人工登录绕过去的）。但这三个小时没有白费：脚本模板里多了三行防御，我知道下一个滑块该怎么先问一句「你是什么类型」，也知道下次看到「所有值都是空的」时，第一件事是去打印原始响应，而不是去加等待时间。


那天晚上我要给一个新平台写自动化发布脚本。跑完之后，脚本打印的每一步都像成功：页面打开了、按钮找到了、图片下载了、坐标算出来了、拖动完成了。退出码 0，没有一行 ERROR，没有一次抛异常。

退出码是 0，日志没有 ERROR，稿子却没发出去：CDP 脚本里的三种静默失败

同一个晚上，同类型的错误出现三次，每一次都安静得像成功：返回值多取一层于是全是空字符串、按钮文字里混了字体图标字符所以永远匹配不上、滑块是白色轮廓型而模板匹配默认它是内容型。每一步都执行了，每一步都「成功」了，结果全是错的。

开发工具

前端

编程语言

CDP脚本静默失败排查：退出码0、无报错但发布失败，源于三层取值错误、文本匹配忽略私用区图标字符、滑块算法假设错误。修复需打印原始响应、归一化文本、独立验证结果，避免防御性代码掩盖错误信号。

代码解释

JavaScript

验证码

容器

JSON

2026上云采购 | AI焕新·智启新局

captcha

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

退出码是 0，日志没有 ERROR，稿子却没发出去：CDP 脚本里的三种静默失败-腾讯云开发者社区-腾讯云

退出码是 0，日志没有 ERROR，稿子却没发出去：CDP 脚本里的三种静默失败

退出码是 0，日志没有 ERROR，稿子却没发出去：CDP 脚本里的三种静默失败

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐