Posts on Fernweh的个人博客

反应测试为什么会多算几十毫秒：按下、松开与浏览器计时

Wed, 09 Sep 2026 00:02:00 +0800

本站反应测试曾出现一个问题：同一个人在其他站点大约测得 220–250 毫秒，在这里却经常超过 300 毫秒。排查后发现，旧实现把鼠标从按下到松开的时间也算进去了。

click 往往比按下更晚

一次常见的鼠标点击包含按下、松开，随后才产生 click。如果测试目标是“看到变绿后，多久按下按钮”，在 click 中计时就可能测到另一个终点。

用可控的浏览器输入进行对照：变绿后 230 毫秒按下，继续按住 80 毫秒再松开。旧实现到松开时记录 310 毫秒；修正后在按下时记录 230 毫秒，松开不会再次计分。

这里的 230 和 80 是测试中指定的时间，不是人的平均反应值，也不是应该给所有成绩减去的固定偏差。

先明确输入的终点

本站现在按以下边界结算：

输入方式	记录时机
鼠标	主按钮的 `pointerdown`
触屏	手指接触面板产生的主指针按下
键盘	空格或回车的首次 `keydown`，忽略按住后的连发
辅助技术的虚拟激活	保留相应的 `click` 路径，并避免重复结算

鼠标或触摸按下已经计分后，其后产生的兼容 click 不应再开新一轮。第二个触点、非主按钮和修饰键组合也不应被当成正常反应。

用事件时间，而不是处理事件时的时间

事件可能先发生，再排队等待主线程处理。假设按下发生在第 230 毫秒，处理函数到第 310 毫秒才执行：直接取处理函数里的 performance.now()，会把这 80 毫秒的排队时间也算进去。

因此，输入端优先采用事件的 timeStamp，并把它归一到与起点一致的时间基准。当前实现的核心调用是：

1
2
3
4
5
6


const pressedAt = inputTime(
 event.timeStamp,
 performance.now(),
 performance.timeOrigin
);
state = respond(state, pressedAt);

归一化会处理异常值，以及使用 Unix 时间而非页面时间基准的旧式时间戳。不能直接把两个不同时间基准的数相减。

这也影响抢跑判断：一个在变绿之前发生、却到变绿后才被处理的输入，仍应判定为抢跑。

变色与起点放到同一个绘制回调

setTimeout 到期表示回调可以运行，不代表屏幕已经变绿。若先开始计时，再等待页面显示，显示延迟也可能被算入成绩。

本站在随机等待结束后，使用同一个动画帧回调更新面板并记录起点。下面省略了暂停与状态检查，仅展示顺序：

1
2
3
4


requestAnimationFrame(() => {
 render('ready');
 state = arm(state, performance.now());
});

requestAnimationFrame 在绘制之前运行，这样能缩小脚本更新与下一次绘制之间的时序差异。它仍不是显示器像素真正发光的时间戳。 屏幕刷新率、输入设备、浏览器和系统调度仍会影响最终测量。

暂停、重开和抢跑也属于计时逻辑

暂停或离开游戏时，需要取消等待定时器和尚未执行的动画帧；恢复后重新等待信号，保留已经完成的成绩。否则旧回调可能突然把新一轮面板变绿。

提前按下不计入五次有效成绩。完成一次后，再按一下面板开始下一次等待。重新开始则清空本局成绩与旧任务。

比较不同站点时，尽量使用相同设备、相同输入方式和相近的前台运行条件。本站修复了可明确定位的事件终点与排队偏差，但浏览器小游戏不能替代专用测量设备。

继续阅读

OpenClaw 装好了却用不了：从运行时到 Gateway 排查

Wed, 09 Sep 2026 00:01:00 +0800

“安装完成”和“可以完成一次任务”之间，还有运行时、Gateway、认证和浏览器连接几个环节。把失败定位到具体环节，才能选对下一步。

先排除命令与运行时问题

在 Windows PowerShell 中检查：

1
2
3


Get-Command node, npm, openclaw -All
node --version
openclaw --version

命令找不到时，先确认安装方式、命令所在目录和当前终端的 PATH。CLI 能被找到后，还要检查运行它的 Node.js 是否符合所用版本的要求。

本机的 Node.js 是 v22.13.1。在隔离目录运行 OpenClaw 2026.9.2 发布包的启动器时，--version 就被以下检查拦住了，退出码为 1：

1

openclaw: Node.js >=22.22.3 <23, >=24.15.0 <25, or >=25.9.0 is required (current: v22.13.1).

这次复现只运行了发布包的启动器和运行时检查，没有进行全局安装或启动 Gateway。它说明：同样叫 Node 22，也不代表满足最低补丁版本。 此时还没进入模型认证或浏览器配对阶段，修改那些配置不会解决这个报错。

2026.9.2 的包元数据和启动器都规定了上述范围。处理时按所用 OpenClaw 版本的要求选受支持的 Node，然后重新检查 node --version 与 openclaw --version。具体安装入口见安装与配置。

CLI 可以运行，再检查 Gateway

下面是 CLI 已经可以执行时的排查步骤，不是上面这台实验环境的成功输出。

1
2
3


openclaw status
openclaw gateway status
openclaw logs --follow

logs --follow 会持续输出日志，看完后用 Ctrl+C 退出。官方排障文档将 Runtime: running、Connectivity probe: ok 和 Capability: ... 列为应关注的 Gateway 信息。字段会随版本变化，要结合完整错误判断。

现象	优先检查
服务没有运行	服务安装方式、启动日志和运行账户
`ECONNREFUSED` / connection refused	目标地址与端口，以及对应服务是否监听
服务运行，但连接探测失败	地址、端口、认证及相关错误；不要把“进程存在”当成连通成功
终端 CLI 与后台服务表现不同	两者使用的 OpenClaw/Node 路径、版本和配置来源是否一致

openclaw doctor 可以提供诊断信息。遇到修复、迁移或重启提示时，先读清楚将改变什么；doctor --fix 和 gateway restart 是会修改状态的操作，应在问题范围明确后使用。

模型请求与浏览器连接分别验证

Gateway 可连接，仍不等于模型请求成功。选择你自己的模型配置完成一次不含敏感内容的简单请求，再依据日志区分认证失败、提供商配额、模型名称或网络问题。401、403、429 应结合具体提供商的错误正文解释。

浏览器连接则按任务选择资料目录与连接模式：

1

openclaw browser --browser-profile openclaw status

上面检查的是独立托管浏览器。需要复用现有登录态时，按浏览器三种模式选择 user 或 chrome 并完成各自授权。网页能打开、扩展已安装、附加到正确标签页是不同的检查点。

记录足够的信息再反馈

保留系统与版本、运行命令、实际地址的非敏感部分、错误时间和对应日志片段。删除令牌、密钥、Cookie 和个人会话内容。

普通 JSON 示例可用JSON 工具检查；两份经过脱敏的示例可用文本 Diff比较。OpenClaw 的完整配置可能是 JSON5，应使用其自身诊断功能，不用普通 JSON 格式化器改写完整配置。

参考

Python 装了包却无法导入：先确认解释器和 pip

Wed, 09 Sep 2026 00:00:00 +0800

pip install 显示成功，运行程序却出现 ModuleNotFoundError，首先需要回答的是：安装包和运行程序，用的是同一个 Python 吗？

下面的例子使用 Windows、Python 3.13.2 和两个独立虚拟环境。重点是找到实际解释器的路径，这个方法也适用于其他 Python 3 版本。

先看命令指向哪里

在运行程序的同一个 PowerShell 窗口中执行：

1
2
3
4


Get-Command python, py, pip -All
python --version
python -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix)"
python -m pip --version

Get-Command 显示命令解析结果；sys.executable 显示真正运行的解释器；python -m pip 让这个解释器加载自己的 pip。仅比较版本号不够，同一个版本也可以存在于多个目录。

在本机，python 指向 D:\JDKs\Python3.13\python.exe，旧版 py 启动器的列表同时包含普通版 3.13、自由线程版 3.13t 和 2.7。py 的默认条目还是 3.13t。因此，直接输入 py 与输入 python 并不一定选择同一套运行时。

旧启动器可用 py --list-paths 查看条目；新版 Python Install Manager 使用 py list。先根据帮助输出判断自己用的是哪一种，再选择明确的版本，例如 py -3.13。安装方式见Python 安装教程。

一次环境错位的实际复现

我在隔离目录创建了 env-a、env-b，并制作了一个名为 blog-env-demo 的本地演示包。它只提供一个字符串，用来验证包安装在哪个环境；它不是需要你从 PyPI 下载的依赖。

两个环境都是 Python 3.13，pip 输出也都是 24.3.1，但路径分别落在各自的目录中。下列输出把实验目录统一缩写为 <实验目录>：

1
2
3
4
5


env-a:
pip 24.3.1 from <实验目录>\env-a\Lib\site-packages\pip (python 3.13)

env-b:
pip 24.3.1 from <实验目录>\env-b\Lib\site-packages\pip (python 3.13)

只给 A 安装演示包后，A 可以导入，B 则报错：

1
2
3
4
5


.\env-a\Scripts\python.exe -c "import blog_env_demo; print(blog_env_demo.MARKER)"
# installed in this interpreter

.\env-b\Scripts\python.exe -c "import blog_env_demo"
# ModuleNotFoundError: No module named 'blog_env_demo'

随后，用 B 自己的解释器执行 -m pip，把同一个本地 wheel 装入 B，B 的导入也成功了。整个过程中没有重装 Python，也没有改全局 PATH。报错来自环境错位。

在自己的项目中怎么修正

先确定项目实际使用的解释器。已有 .venv 时，可以直接检查它：

1
2


.\.venv\Scripts\python.exe -c "import sys; print(sys.executable)"
.\.venv\Scripts\python.exe -m pip --version

如果这是尚未创建虚拟环境的新项目，再用已安装的目标版本创建环境：

1

py -3.13 -m venv .venv

在提供了 requirements.txt 的项目中，让安装和运行使用同一路径：

1
2


.\.venv\Scripts\python.exe -m pip install -r requirements.txt
.\.venv\Scripts\python.exe app.py

将版本号、依赖文件和入口文件替换为项目实际使用的值。IDE、调试器、定时任务也应选同一个解释器。直接调用 .venv 中的 Python 不要求先运行激活脚本，因此也不必为此修改 PowerShell 执行策略。

路径一致后，还需要检查什么

现象	下一步
安装名和导入名不同	查包的使用文档，例如安装 `Pillow` 后导入的是 `PIL`
报错指向项目内的同名文件	检查是否用 `json.py`、`requests.py` 等文件名遮蔽了真正的模块
pip 有包，IDE 仍报错	查看 IDE 当前运行配置中的解释器路径，而不只看终端状态
自由线程版与普通版混用	核对运行时及二进制扩展支持情况，不直接复制另一个环境的 `site-packages`

sys.prefix != sys.base_prefix 通常表示当前解释器处于虚拟环境。最终应以实际运行程序的解释器和完整错误为准。

参考

保护 Linux 服务器的一大利器：Fail2ban

Wed, 01 Apr 2026 15:00:00 +0800

Fail2ban 根据日志中的失败事件执行封禁动作。它能补充 SSH 等服务的防护，但需要正确的日志来源、过滤器和防火墙动作；安装服务本身不等于已经保护所有入口。

适用范围与安装

下面以使用 systemd 的 Debian/Ubuntu 软件包环境和 SSH 为例。先核对发行版、SSH 实际端口及 Fail2ban 软件包版本；Fedora、RHEL 和其他发行版的仓库与日志配置不能直接套用。

1
2
3


sudo apt update
sudo apt install fail2ban
fail2ban-client --version

优先使用发行版维护的软件包。确需源码安装时，按上游说明选择版本，并确认依赖、服务文件和后续升级方式。

先确认 SSH 日志在哪里

Ubuntu/Debian 常见服务单元为 ssh，其他环境可能是 sshd。检查实际单元及日志：

1
2


sudo systemctl status ssh --no-pager
sudo journalctl -u ssh -n 30 --no-pager

如果使用文件日志，先确认 /var/log/auth.log 等文件确实存在且包含 SSH 认证事件。不要仅因为某篇教程写了该路径，就假定机器正在向它写日志。

用小型覆盖文件配置 SSH jail

保留发行版的 jail.conf，在 /etc/fail2ban/jail.d/sshd.local 中写入需要覆盖的参数，避免复制整份默认配置后长期失去上游更新。

启用前先确保有第二条管理会话或控制台，并将确认过的固定管理地址加入 ignoreip。下面只列出回环地址；它不包含你的远程管理地址。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


[DEFAULT]
ignoreip = 127.0.0.1/8 ::1

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

使用自定义 SSH 端口时，将 port 改为实际端口。
systemd 后端读取 journal，不能同时照抄文件型 logpath。
若改用文件日志，选择合适的文件后端，并设置已确认的路径，例如 backend = polling 配合 logpath = /var/log/auth.log。
maxretry 和 findtime 控制触发条件；bantime 是封禁时长，按业务和恢复能力调整。

验证配置后再启用

1

sudo fail2ban-client -t

配置检查通过后，再启用或重新加载服务：

1
2
3
4
5


sudo systemctl enable --now fail2ban
sudo fail2ban-client reload
sudo fail2ban-client ping
sudo fail2ban-client status
sudo fail2ban-client status sshd

确认 sshd 已启用、日志来源正确，并检查实际的封禁动作。需要测试封禁时，使用受控测试来源并保留恢复入口，不要反复用唯一管理连接试错。

封禁、解禁与持久化

下面的 192.0.2.10 是文档示例地址，操作前替换为经过核实的目标：

1
2
3


sudo fail2ban-client set sshd banip 192.0.2.10
sudo fail2ban-client set sshd unbanip 192.0.2.10
sudo fail2ban-client unban 192.0.2.10

上游默认配置启用 SQLite 持久化，dbfile 为 /var/lib/fail2ban/fail2ban.sqlite3。因此不能笼统地说“重启后所有封禁都会失效”；恢复结果还受数据库、封禁剩余时间、清理策略和发行版配置影响。应检查当前有效配置和服务重启后的实际状态。

扩展到其他服务前

不要只添加一个不存在过滤器的 nginx-404 jail。先确认过滤器文件、真实日志格式和误报范围，再用 fail2ban-regex 对受控样例验证。JavaScript 正则工具也不能替代 Fail2ban 自身的过滤器测试。

如果没有封禁事件，按“日志是否产生 → 后端是否读取 → 过滤器是否匹配 → 防火墙动作是否成功”的顺序排查。修改配置后先运行 fail2ban-client -t，不要靠反复重启猜测原因。

官方依据

OpenClaw 浏览器三种模式：托管、MCP 与 Chrome 扩展

Tue, 24 Mar 2026 23:00:00 +0800

OpenClaw 提供三种浏览器模式：隔离的 openclaw、基于 Chrome DevTools MCP 的 user，以及基于 Chrome 扩展的 chrome。它们主要区别在于是否复用个人登录态，以及连接时需要怎样的授权。

先选择连接模式

配置名	连接对象	适合的情况
`openclaw`	OpenClaw 管理的独立浏览器资料目录	自动化练习、测试，不需要个人浏览器登录态
`user`	通过 Chrome DevTools MCP 附加到已运行的浏览器	需要现有登录态，且有人在电脑前确认连接
`chrome`	通过 OpenClaw Chrome 扩展连接浏览器	需要现有登录态并已完成扩展安装、配对

独立浏览器是默认选择。两种复用登录态的方式都会扩大自动化能访问的内容，选择时应以任务需要和浏览器权限为准。

使用独立托管浏览器

在 Gateway 已可用的前提下：

1
2
3
4


openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw snapshot

这组命令可以分别核对状态、启动浏览器、打开测试网页和读取快照。仅命令退出成功，不能替代实际页面和快照结果的检查。

使用 `user` 连接已有 Chrome

user 模式要求目标 Chromium 浏览器为 144+，并启用远程调试。

保持目标 Chrome 运行，在地址栏打开 chrome://inspect/#remote-debugging。
在该页面启用远程调试。
运行连接命令，在浏览器出现授权提示时人工确认：

1
2
3
4


openclaw browser --browser-profile user start
openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user snapshot --format ai

user 是内置配置名，无需为最简单场景手写整份配置。成功时，状态应包含 driver: existing-session、transport: chrome-mcp 和 running: true；标签页列表与快照还应对应实际浏览器。

Brave、Edge 或其他资料目录可能需要显式设置 userDataDir；已经用调试端口启动的浏览器可能需要 cdpUrl。这些属于不同连接条件，按官方已有会话说明配置。

Chrome 扩展仍是支持的方式

当前官方扩展入口为：

1

openclaw browser extension install

然后依照扩展文档完成安装、授权和配对。macOS/Linux 的本地主机引导与 Windows 的手动配对流程不同，请选择对应系统的步骤。

完成配对后，使用 chrome 配置检查连接：

1
2


openclaw browser --browser-profile chrome status
openclaw browser --browser-profile chrome tabs

排查顺序

没有 browser 子命令：核对 OpenClaw 版本和浏览器插件是否启用。
无法附加 user：核对浏览器版本、远程调试开关、授权提示和目标资料目录。
状态正常但看不到目标页面：先确认使用了正确的 profile，再检查 tabs 返回内容。
扩展无法连接：检查当前操作系统对应的安装和配对流程，不能用 MCP 的调试开关代替扩展配对。

官方依据

OpenClaw 安装与配置：环境检查与验收

Mon, 23 Mar 2026 22:00:00 +0800

OpenClaw 可以在自己的设备上运行 Gateway，并连接聊天渠道和模型服务。本篇按“检查环境 → 选择安装方式 → 初始化 → 验收”的顺序整理官方 CLI 流程。

先检查适用环境

官方安装页列出的 Node.js 范围为 22.22.3+、24.15+ 或 25.9+，推荐 Node 26。Windows 用户可以选择原生 Windows Hub、PowerShell CLI 或 WSL2；这里主要介绍 CLI。

先记录实际版本，再选用对应命令：

1
2


node --version
npm --version

模型认证方式取决于提供商。按照初始化向导在自己的设备上完成认证，不把密钥写进截图、分享链接或问题报告。安装器、初始化和守护进程步骤会改变本机环境。

方式一：通过包管理器安装

使用 npm 12 或 npm 11.16+ 时，官方当前命令显式允许 OpenClaw 自身的安装脚本：

1

npm install -g openclaw@latest --allow-scripts=openclaw

npm 11.15 及更早版本不支持上述选项，使用：

1

npm install -g openclaw@latest

如果使用 pnpm，当前官方全局安装方式为：

1

pnpm add -g --allow-build=openclaw openclaw@latest

pnpm approve-builds -g 不是当前支持的全局安装流程。latest 会变化；需要复现时，应先确认具体发布版本，再将其替换为明确版本号并记录 Node、包管理器和操作系统版本。

方式二：使用官方安装脚本

脚本可能安装或切换 Node.js、安装 OpenClaw 并启动向导。先下载并阅读，再决定是否执行；有发布方校验信息时一并核对。

macOS / Linux / WSL2

1
2
3
4
5


installer_path="$(mktemp)"
curl -fL https://openclaw.ai/install.sh -o "$installer_path"
less "$installer_path"
# 审阅完成后执行
bash "$installer_path"

Windows PowerShell

1
2
3
4
5


$installerPath = Join-Path $env:TEMP 'openclaw-install.ps1'
Invoke-WebRequest -Uri 'https://openclaw.ai/install.ps1' -OutFile $installerPath
Get-Content -LiteralPath $installerPath
# 审阅完成后执行
& $installerPath

本篇使用官方 OpenClaw 发行版。第三方分支、国内镜像可能采用不同的包名、配置和版本，应按其各自文档安装。源码构建请按官方安装页对应版本的 pnpm 要求操作。

初始化和验收

如果安装器尚未运行初始化向导：

1

openclaw onboard --install-daemon

该命令会配置模型、Gateway 和后台启动方式。完成后分别检查 CLI 和服务：

1
2
3
4


openclaw --version
openclaw doctor
openclaw gateway status
openclaw dashboard

doctor 是诊断入口，某些版本可能提示迁移或修复配置；先阅读输出再接受变更。能输出版本号不等于 Gateway 已运行，打开 Dashboard 也不等于已经完成一次模型请求。

常见失败与下一步

找不到 openclaw：重新打开终端，检查 npm prefix -g 和命令搜索路径，确认使用的是安装时的 Node 环境。
安装脚本未获允许：先核对 npm/pnpm 版本和上面的许可选项，不要批量允许不认识的包。
Gateway 未运行：查看 openclaw gateway status 的服务与连接信息，再按官方排障页定位。

下一篇介绍浏览器的三种连接方式。普通 JSON 示例可以用本站 JSON 工具检查语法；完整 JSON5 配置仍应由 OpenClaw 自身诊断。

官方依据

如何彻底卸载 OpenClaw 小龙虾

Wed, 18 Mar 2026 17:22:00 +0800

卸载 OpenClaw 涉及不同范围：Gateway 服务、状态目录、工作区、桌面应用和 CLI 包。先确定哪些内容需要保留，并确认备份，再开始清理。

优先使用内置卸载器

CLI 仍可用时，先预览所有清理范围：

1

openclaw uninstall --dry-run --all

核对实际目录和服务后，进入交互式卸载：

1

openclaw uninstall

当前官方交互流程初始只选中 Gateway 服务，状态、工作区和应用是独立选项；--all 会选择全部四项。删除状态不等于删除配置过的工作区。服务移除失败时，相关数据范围可能被保留，并报告部分清理失败。

如果 CLI 已删除但后台服务仍在，按官方手动移除说明处理对应操作系统的服务，不要终止所有 Node.js 进程。

下面的附带脚本只负责范围更窄的包、进程和 Docker 资源盘点及清理，不能替代内置卸载器对服务、状态和工作区的处理。

自动化卸载脚本（先检查，再执行）

清理脚本默认只做 dry-run（只读盘点），列出检测到的 OpenClaw 全局包、命令行明确包含 OpenClaw 的 Node.js 进程，以及当前 Docker 上下文中名称或镜像明确匹配 OpenClaw 的资源。脚本不会停止全部 Node.js 进程，也不会扫描或删除用户目录、配置文件、注册表或任意 Docker 资源。

不要使用 curl | bash 或 irm | iex 直接执行远程脚本。请先下载、核对 SHA-256、阅读内容，再运行 dry-run。确认清单无误后使用 -Apply/--apply；交互模式还会要求输入 REMOVE OPENCLAW。

Windows（PowerShell）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


$scriptUrl = 'https://blog.codeglimpse.top/post/openclaw-uninstall/CleanupOpenClawForWindows.ps1'
$scriptPath = Join-Path $env:TEMP 'CleanupOpenClawForWindows.ps1'
Invoke-WebRequest -Uri $scriptUrl -OutFile $scriptPath

$expectedSha256 = 'eab731bd073f42fb75569be6c1dd3af37aca3214957057241ed13072fcc40daa'
if ((Get-FileHash -Algorithm SHA256 -LiteralPath $scriptPath).Hash.ToLowerInvariant() -ne $expectedSha256) {
 throw 'SHA-256 校验失败，请勿执行该文件。'
}

Get-Content -LiteralPath $scriptPath
& $scriptPath # dry-run，只读盘点
& $scriptPath -Apply # 查看同一清单并要求明确确认后执行

通常不需要管理员权限；只有当前安装位置或 Docker 环境本身要求提升权限时，才应使用管理员终端。-Apply -Yes 仅用于你已经审核过清单的受控自动化环境。

Linux（Bash）

1
2
3
4
5
6
7


script_path="$(mktemp)"
curl -fL 'https://blog.codeglimpse.top/post/openclaw-uninstall/CleanupOpenClawForLinux.sh' -o "$script_path"
printf '%s %s\n' '0cfab4f8823a1644ef2e5b47275b144417c271372b7b11b795cf8c60a6689cb8' "$script_path" | sha256sum -c -

less "$script_path"
bash "$script_path" # dry-run，只读盘点
bash "$script_path" --apply # 要求输入 REMOVE OPENCLAW 后执行

macOS（Bash）

1
2
3
4
5
6
7


script_path="$(mktemp)"
curl -fL 'https://blog.codeglimpse.top/post/openclaw-uninstall/CleanupOpenClawForMacOS.sh' -o "$script_path"
printf '%s %s\n' 'a7e6048a20a933e4297edfe64847afc8f5a206add153502ff6ac260be9d7a801' "$script_path" | shasum -a 256 -c -

less "$script_path"
bash "$script_path" # dry-run，只读盘点
bash "$script_path" --apply # 要求输入 REMOVE OPENCLAW 后执行

卸载 CLI 包并验收

处理完所选服务和数据范围后，使用当初安装它的包管理器卸载 CLI。下列命令按实际情况选择一种：

1
2
3
4
5


# npm 安装
npm uninstall -g openclaw

# pnpm 安装
pnpm remove -g openclaw

openclaw-cn 等第三方分支应单独确认。按实际包前缀和已审核清单处理残留，不照抄猜测的全局安装路径直接删除。随后检查原服务和命令搜索结果；仅 CLI 命令消失不能证明后台服务已经移除。

常见问题

权限不足时，先确认安装位置或 Docker 环境的实际要求，不统一使用管理员权限处理所有清理步骤。
找不到命令时，核对当初安装使用的 PATH 和包管理器环境；脚本清单只覆盖实际检测到的范围。
dry-run 只报告计划，实际完成情况还要检查执行结果、剩余服务与资源。

官方依据

OpenClaw 卸载范围、预览与手动服务移除

Python 下载与安装教程

Sun, 28 Sep 2025 16:20:00 +0800

先选择适合项目的 Python 版本，再确认实际执行的解释器，最后为项目创建虚拟环境。以下介绍 Python 3.14 的安装方式；独立安装器的截图展示的是 3.12/3.13 界面。

Windows：优先了解 Python Install Manager

官方目前推荐从 python.org 或 Microsoft Store 获取 Python Install Manager。它与旧版独立 .exe 安装器及旧 py 启动器需要区分；遇到命令冲突时先查看官方 Windows 文档。

安装管理器后，在 PowerShell 中确认可用命令，再安装所需版本。以下以 3.14 为例，实际项目仍需检查依赖兼容性：

1
2
3
4
5


py help
py install 3.14
py list
py -3.14 --version
py -3.14 -c "import sys; print(sys.executable)"

管理器会下载运行时。Python 3.14 的 Windows 支持范围见官方说明；不要把旧系统支持和当前受维护系统混为一谈。

已有 3.12/3.13 独立安装器时

旧界面仍可能在已有环境中出现。一般开发场景先选择当前用户安装；只有明确需要所有用户共用时，才选择系统范围安装并提升权限。py 启动器提供版本选择，不等于所有终端中的 python 都会指向同一个解释器。

安装时保留 pip；调试符号、调试二进制和完整标准库测试套件是按需组件。PATH 和文件关联也应结合已有解释器决定，不要统一勾选全部选项。

静默安装必须使用已经下载并核对的具体安装器文件名。例如，下面的参数用于旧安装器的当前用户安装：

1
2


# 将文件名替换为已核对的安装包
./python-3.13.7-amd64.exe /quiet InstallAllUsers=0 PrependPath=1 Include_test=0

这里的文件名仅演示旧安装器语法，不表示 3.13.7 是推荐下载的最新补丁版本。3.14 文档已将完整安装器列为弃用方式，新环境应先评估安装管理器。

macOS

使用官方安装包

从 Python for macOS 下载与你的 macOS 和处理器兼容的安装包，阅读安装器中的支持范围与许可说明。

安装完成后，按当前安装器说明运行对应版本目录中的 Install Certificates.command。它会联网安装该 Python 使用的证书组件。不要照抄旧截图中的版本目录。

1
2


python3 --version
python3 -c "import sys; print(sys.executable)"

不要删除或修改 Apple 管理的 /usr/bin/python3。官方 Python 可以与系统开发工具使用的解释器并存。

已使用 Homebrew 时

先查看 Homebrew 当前安装要求。其要求涉及受支持的 macOS、硬件和 Xcode Command Line Tools，不能概括为“必须先安装系统 Python”。

在 Homebrew 已正常配置的终端中：

1
2
3
4


brew --version
brew install python
python3 --version
command -v python3

如果尚未安装 Homebrew，先按官网说明下载、审阅安装脚本再执行。出现路径冲突时先检查终端配置，不要直接强制覆盖链接。

Linux：使用发行版软件包

Debian / Ubuntu

1
2
3


sudo apt update
sudo apt install python3 python3-pip python3-venv
python3 --version

安装 Python 不需要顺带升级整台机器、修改整个 ~/.local 的所有者或删除 APT 锁文件。遇到锁占用时，先确认另一个包管理任务是否仍在运行，等待完成或按发行版的故障处理流程排查。

Fedora

1
2


sudo dnf install python3 python3-pip
python3 --version

RHEL 及其他发行版的软件包版本和仓库策略不同，应按对应发行版文档选择。不要替换系统 Python，也不要默认使用 sudo pip 安装项目依赖。

为每个项目创建虚拟环境

在项目目录中执行。Windows 示例明确使用已安装的 3.14：

1
2
3


py -3.14 -m venv .venv
.\.venv\Scripts\python.exe --version
.\.venv\Scripts\python.exe -m pip --version

macOS / Linux：

1
2
3


python3 -m venv .venv
.venv/bin/python --version
.venv/bin/python -m pip --version

直接调用虚拟环境中的解释器即可，不必为了运行示例而修改 PowerShell 执行策略。安装依赖时沿用同一个解释器的 -m pip。

验收与常见问题

记录操作系统、--version 输出、sys.executable 和 pip --version，确认它们属于预期环境。
python 打开商店或版本不对：检查应用执行别名、py list 与 PATH。
提示 externally-managed-environment：为项目创建虚拟环境，不绕过发行版保护。
缺少 venv/ensurepip：安装发行版对应的虚拟环境组件，再重新创建环境。

Posts on Fernweh的个人博客

反应测试为什么会多算几十毫秒：按下、松开与浏览器计时

click 往往比按下更晚

先明确输入的终点

用事件时间，而不是处理事件时的时间

变色与起点放到同一个绘制回调

暂停、重开和抢跑也属于计时逻辑

继续阅读

OpenClaw 装好了却用不了：从运行时到 Gateway 排查

先排除命令与运行时问题

CLI 可以运行，再检查 Gateway

模型请求与浏览器连接分别验证

记录足够的信息再反馈

参考

Python 装了包却无法导入：先确认解释器和 pip

先看命令指向哪里

一次环境错位的实际复现

在自己的项目中怎么修正

路径一致后，还需要检查什么

参考

保护 Linux 服务器的一大利器：Fail2ban

适用范围与安装

先确认 SSH 日志在哪里

用小型覆盖文件配置 SSH jail

验证配置后再启用

封禁、解禁与持久化

扩展到其他服务前

官方依据

OpenClaw 浏览器三种模式：托管、MCP 与 Chrome 扩展

先选择连接模式

使用独立托管浏览器

使用 user 连接已有 Chrome

Chrome 扩展仍是支持的方式

排查顺序

官方依据

OpenClaw 安装与配置：环境检查与验收

先检查适用环境

方式一：通过包管理器安装

方式二：使用官方安装脚本

macOS / Linux / WSL2

Windows PowerShell

初始化和验收

常见失败与下一步

官方依据

如何彻底卸载 OpenClaw 小龙虾

优先使用内置卸载器

自动化卸载脚本（先检查，再执行）

Windows（PowerShell）

Linux（Bash）

macOS（Bash）

卸载 CLI 包并验收

常见问题

官方依据

Python 下载与安装教程

Windows：优先了解 Python Install Manager

已有 3.12/3.13 独立安装器时

macOS

使用官方安装包

已使用 Homebrew 时

Linux：使用发行版软件包

Debian / Ubuntu

Fedora

为每个项目创建虚拟环境

验收与常见问题

官方依据

使用 `user` 连接已有 Chrome