如果你有网页截图、自动化测试、数据抓取或者 AI Agent 调浏览器的需求，把 Chromium 直接塞进业务容器通常会越来越乱。更稳妥的做法，是把浏览器能力单独拆成一个 Browserless 服务，业务侧通过远程连接去调用它。
Browserless 的价值在哪里
Browserless 本质上是“把无头浏览器变成一个可复用服务”。这样做的好处很直接：浏览器版本集中管理，资源限制统一控制，多个应用可以复用同一套浏览器环境。对于小团队来说，这比每个项目各自维护 Playwright 或 Puppeteer 运行环境省事很多。
compose 里的关键配置
下面这份配置已经带上了几个比较实用的参数：
services:
browserless:
image: browserless/chrome:latest
container_name: browserless
restart: unless-stopped
environment:
- TZ=Asia/Shanghai
- MAX_CONCURRENT_SESSIONS=5
- MAX_QUEUE_LENGTH=50
- PREBOOT_CHROME=true
- CONNECTION_TIMEOUT=300000
- TOKEN=050y4Pciocxu4Y
deploy:
resources:
limits:
cpus: '2'
memory: 4G这里最值得注意的是并发数、队列长度和超时时间。它们直接决定高峰期请求是排队、失败，还是把机器拖慢。PREBOOT_CHROME=true 则能减少首次启动浏览器时的等待。
部署命令可以很简单
建议先单独建目录：
mkdir -p ~/apps/browserless
cd ~/apps/browserless写好 compose.yml 后启动：
docker compose up -d
docker compose logs -f如果你希望被外部程序直接访问，还需要暴露服务端口，常见做法是加一行 3000:3000，或者只放进内网网络里，通过反向代理统一转发。
TOKEN 一定不要照搬示例值
示例里的 TOKEN=050y4Pciocxu4Y 只适合演示，生产环境务必改成你自己的随机高强度值。否则任何拿到地址的人都可能调用你的浏览器服务，轻则抢占资源，重则把它当成开放代理或自动化攻击入口。最少也应该改成随机长字符串，并限制来源网络。
适合哪些实际场景
最常见的有四类：网页截图服务、Puppeteer/Playwright 远程执行、登录后页面抓取，以及给 AI 工作流补上“真实浏览器”能力。如果你在做知识采集、网页归档、海报截图或自动化巡检，Browserless 都很顺手。
资源规划别拍脑袋
浏览器是吃内存的，尤其是页面复杂、并发较高时更明显。示例里限制为 2 核和 4G 内存，是一个比较稳妥的起点，但并不代表所有场景都够用。上线后最好根据真实任务量观察容器内存占用和排队情况，再调 MAX_CONCURRENT_SESSIONS。并发开太大，往往不是更快，而是整体更容易抖。