安卓Termux上跑浏览器自动化的坑与实战

这周末在安卓 Termux 上折腾「头条号 + 公众号自动发布」，被同一个坑反复折磨了两天：Chromium 页面总是无缘无故崩溃，浏览器一启动就 "Page crashed"，排障脚本跑一半就死，死活起不来。今天把完整的定位思路和解决方案记下来，希望能帮到同样在手机/低配 Linux 上跑自动化脚本的朋友。

一、现象：一切正常，唯独 Chromium 崩

我的目标很简单：用 Playwright 驱动 Chromium，在手机上无头跑浏览器自动化（登录、抓数据、发布）。代码在电脑上跑得飞快，可一搬到 Termux 就各种"灵异"：

• 浏览器进程能起来，但页面一加载就报 Page crashed / Target page closed。
• 偶尔能截图，但多开几个标签页就崩。
• 报错信息飘忽不定，像是内存不足，又像是权限问题。

二、定位：不是内存，是共享内存

一开始以为是手机内存不够。但一查，问题根本不在内存，而在一个常被忽略的目录：/dev/shm（共享内存）。

Chromium 的渲染进程为了跨进程通信，要在共享内存上做很多操作。但安卓的沙箱（untrusted_app）默认没有 /dev/shm，也没有 /tmp。于是 Chromium 一上来就撞墙——它找不到共享内存，渲染进程直接崩溃，整个页面跟着完蛋。

我试着 mount -t tmpfs tmpfs /data/data/com.termux/files/usr/tmp/shm 手动挂载，结果被系统无情拒绝：安卓沙箱禁止 mount。这条路走不通。

三、方案一：给启动参数打补丁（没用）

第一反应是加启动参数，网上都说这样能救：

--no-sandbox --disable-gpu --disable-dev-shm-usage --disable-software-rasterizer

把 --disable-dev-shm-usage 加上后，Chromium 确实会改去用 /tmp。可问题是——Termux 连 /tmp 都没有！加了参数还是崩，报错依旧。

这一步教训：加参数前先搞清楚缺的到底是哪个资源。缺 /dev/shm 用 --disable-dev-shm-usage 有用；可如果连 /tmp 也没有，这个参数反而把问题搬到另一个空目录里，白忙。

四、方案二（正解）：复用已有的 CDP 浏览器

转机在于：我发现机器上早就跑着一个稳定了数天的 Chromium（微信公众平台用的），它通过 --remote-debugging-port=9222 开放了 CDP 调试端口。这个实例因为共享内存早就"热"了，所以一直没崩。

于是思路变了：既然开新浏览器必崩，那就别开新的，直接用现成的。

Playwright 原生支持连接已有的浏览器：

const browser = await chromium.connectOverCDP('http://127.0.0.1:9222'); const context = await browser.newContext(); const page = await context.newPage(); await page.goto('https://example.com');

关键点：连接后要用 newContext() 开一个隔离的上下文，这样既不会污染原来微信的登录态，又能正常跑自己的自动化。connectOverCDP 走的是已有的调试通道，不启动新进程，自然不碰 /dev/shm 的坑。

五、扫码登录的另一个坑：二维码会被"刷新"作废

自动化登录要走扫码。结果又踩一坑：我的轮询脚本每 50 秒刷新一次二维码，可用户扫完码、还没点确认，刷新一来直接把刚扫的码作废，导致"明明扫了却登录不上"。

修法很简单：把二维码固定住，至少 110 秒不刷新，给用户留足扫码+确认的时间；超过时限才换新码。细节决定成败，这类交互类的 bug 最容易被忽略。

六、总结：三条可复用的经验

2. 先定位资源瓶颈，再对症下药。
   缺 /dev/shm 和缺 /tmp 是两回事，盲目加参数没用。
4. 别轻易开新进程。
   共享内存不足的环境，复用已有的 CDP 浏览器（connectOverCDP + newContext）是最稳的路子。
6. 交互类自动化注意时序。
   像二维码这种一次性的东西，别用会"刷新作废"的逻辑去轮询。

手机跑浏览器自动化，本质是在各种资源受限的环境里找平衡。很多时候，问题不在代码，而在环境——换个思路，往往比死磕参数快得多。