根本原因是linux后台进程（如crontab、systemd）的path极简，不包含chrome默认安装路径（如/opt/google/chrome/chrome），导致shutil.which()查不到；必须显式设置chromiumoptions.binary_location为完整可执行文件路径，并确保home环境变量正确。
为什么Linux下Selenium/DrissionPage总报“找不到浏览器可执行文件”
根本原因不是浏览器没装，而是Python进程压根没去查你装Chrome的地方。Linux的crontab、systemd或后台服务启动时，PATH环境变量极简，通常只含/usr/bin和/bin；而Chrome稳定版默认装在/opt/google/chrome/chrome，Chromium可能是/usr/bin/chromium-browser——这两个路径都不在默认PATH里。Selenium和DrissionPage默认靠shutil.which("chrome")或类似逻辑找浏览器，一查就空。
用ChromeOptions.binary_location硬编码路径最可靠
别依赖环境变量，直接告诉WebDriver“浏览器就在这个绝对路径”。这是跨环境（本地、crontab、Docker、systemd）唯一稳的写法。
-
ChromeOptions必须显式设置binary_location，否则它会跳过二进制查找逻辑，直接报错 - 路径必须是
chrome或chromium可执行文件本身，不能只给目录（比如/opt/google/chrome不行，得是/opt/google/chrome/chrome） - 确认路径真实存在且有执行权限：
ls -l /opt/google/chrome/chrome，输出里要有x - 示例代码：
from selenium import webdriver from selenium.webdriver.chrome.options import Options <p>opts = Options() opts.binary_location = "/opt/google/chrome/chrome" # ← 必须是完整可执行文件路径 driver = webdriver.Chrome(options=opts) </p>
DrissionPage怎么配binary_location
DrissionPage 4.x+ 不再通过browser.py手动改源码，而是支持原生传参。直接在ChromiumOptions里设binary_location，比改源码安全得多。
- 不要去动
browser.py里的_run_browser函数——那属于旧版本hack，新版不兼容且易被覆盖 - 正确做法是构造
ChromiumOptions对象后赋值：options.binary_location = "/opt/google/chrome/chrome" - 如果用
DriveSession初始化，必须把options对象传进去，不能只传路径字符串 - 示例：
from DrissionPage import ChromiumOptions, DriveSession <p>co = ChromiumOptions() co.binary_location = "/opt/google/chrome/chrome" session = DriveSession(co) </p>
crontab里跑脚本还要注意PATH和HOME
即使写了binary_location，crontab仍可能因HOME缺失导致Chrome启动失败（比如找不到用户配置目录）。这不是路径问题，但常被误判为“还是找不到”。
- crontab默认
HOME=/，而Chrome需要读写$HOME/.config/google-chrome，所以得显式指定HOME - 推荐在crontab条目开头加环境变量：
HOME=/home/youruser PATH=/usr/local/bin:/usr/bin:/bin - 或者在Python脚本里临时设置：
import os; os.environ["HOME"] = "/home/youruser" - 验证方法：crontab里先跑
which chrome和echo $HOME，确认输出符合预期
真正卡住人的从来不是“怎么写代码”，而是Linux里每个进程都活在自己的环境变量牢笼里。硬编码binary_location只是第一步，HOME和PATH才是crontab场景下静默失败的元凶。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
