[{"content":"本站反应测试曾出现一个问题：同一个人在其他站点大约测得 220–250 毫秒，在这里却经常超过 300 毫秒。排查后发现，旧实现把鼠标从按下到松开的时间也算进去了。\nclick 往往比按下更晚 一次常见的鼠标点击包含按下、松开，随后才产生 click。如果测试目标是“看到变绿后，多久按下按钮”，在 click 中计时就可能测到另一个终点。\n用可控的浏览器输入进行对照：变绿后 230 毫秒按下，继续按住 80 毫秒再松开。旧实现到松开时记录 310 毫秒；修正后在按下时记录 230 毫秒，松开不会再次计分。\n这里的 230 和 80 是测试中指定的时间，不是人的平均反应值，也不是应该给所有成绩减去的固定偏差。\n先明确输入的终点 本站现在按以下边界结算：\n输入方式 记录时机 鼠标 主按钮的 pointerdown 触屏 手指接触面板产生的主指针按下 键盘 空格或回车的首次 keydown，忽略按住后的连发 辅助技术的虚拟激活 保留相应的 click 路径，并避免重复结算 鼠标或触摸按下已经计分后，其后产生的兼容 click 不应再开新一轮。第二个触点、非主按钮和修饰键组合也不应被当成正常反应。\n用事件时间，而不是处理事件时的时间 事件可能先发生，再排队等待主线程处理。假设按下发生在第 230 毫秒，处理函数到第 310 毫秒才执行：直接取处理函数里的 performance.now()，会把这 80 毫秒的排队时间也算进去。\n因此，输入端优先采用事件的 timeStamp，并把它归一到与起点一致的时间基准。当前实现的核心调用是：\n1 2 3 4 5 6 const pressedAt = inputTime( event.timeStamp, performance.now(), performance.timeOrigin ); state = respond(state, pressedAt); 归一化会处理异常值，以及使用 Unix 时间而非页面时间基准的旧式时间戳。不能直接把两个不同时间基准的数相减。\n这也影响抢跑判断：一个在变绿之前发生、却到变绿后才被处理的输入，仍应判定为抢跑。\n变色与起点放到同一个绘制回调 setTimeout 到期表示回调可以运行，不代表屏幕已经变绿。若先开始计时，再等待页面显示，显示延迟也可能被算入成绩。\n本站在随机等待结束后，使用同一个动画帧回调更新面板并记录起点。下面省略了暂停与状态检查，仅展示顺序：\n1 2 3 4 requestAnimationFrame(() =\u0026gt; { render(\u0026#39;ready\u0026#39;); state = arm(state, performance.now()); }); requestAnimationFrame 在绘制之前运行，这样能缩小脚本更新与下一次绘制之间的时序差异。它仍不是显示器像素真正发光的时间戳。 屏幕刷新率、输入设备、浏览器和系统调度仍会影响最终测量。\n暂停、重开和抢跑也属于计时逻辑 暂停或离开游戏时，需要取消等待定时器和尚未执行的动画帧；恢复后重新等待信号，保留已经完成的成绩。否则旧回调可能突然把新一轮面板变绿。\n提前按下不计入五次有效成绩。完成一次后，再按一下面板开始下一次等待。重新开始则清空本局成绩与旧任务。\n比较不同站点时，尽量使用相同设备、相同输入方式和相近的前台运行条件。本站修复了可明确定位的事件终点与排队偏差，但浏览器小游戏不能替代专用测量设备。\n继续阅读 本站反应测试 反应测试控制器源码 MDN：pointerdown MDN：Event.timeStamp MDN：requestAnimationFrame ","description":"结合本站反应测试的实际修复，解释 click、pointerdown、事件时间戳和绘制帧如何影响测量。","permalink":"https://blog.codeglimpse.top/p/reaction-timing/","tags":["JavaScript","Games"],"title":"反应测试为什么会多算几十毫秒：按下、松开与浏览器计时"},{"content":"“安装完成”和“可以完成一次任务”之间，还有运行时、Gateway、认证和浏览器连接几个环节。把失败定位到具体环节，才能选对下一步。\n先排除命令与运行时问题 在 Windows PowerShell 中检查：\n1 2 3 Get-Command node, npm, openclaw -All node --version openclaw --version 命令找不到时，先确认安装方式、命令所在目录和当前终端的 PATH。CLI 能被找到后，还要检查运行它的 Node.js 是否符合所用版本的要求。\n本机的 Node.js 是 v22.13.1。在隔离目录运行 OpenClaw 2026.9.2 发布包的启动器时，--version 就被以下检查拦住了，退出码为 1：\n1 openclaw: Node.js \u0026gt;=22.22.3 \u0026lt;23, \u0026gt;=24.15.0 \u0026lt;25, or \u0026gt;=25.9.0 is required (current: v22.13.1). 这次复现只运行了发布包的启动器和运行时检查，没有进行全局安装或启动 Gateway。它说明：同样叫 Node 22，也不代表满足最低补丁版本。 此时还没进入模型认证或浏览器配对阶段，修改那些配置不会解决这个报错。\n2026.9.2 的包元数据和启动器都规定了上述范围。处理时按所用 OpenClaw 版本的要求选受支持的 Node，然后重新检查 node --version 与 openclaw --version。具体安装入口见安装与配置。\nCLI 可以运行，再检查 Gateway 下面是 CLI 已经可以执行时的排查步骤，不是上面这台实验环境的成功输出。\n1 2 3 openclaw status openclaw gateway status openclaw logs --follow logs --follow 会持续输出日志，看完后用 Ctrl+C 退出。官方排障文档将 Runtime: running、Connectivity probe: ok 和 Capability: ... 列为应关注的 Gateway 信息。字段会随版本变化，要结合完整错误判断。\n现象 优先检查 服务没有运行 服务安装方式、启动日志和运行账户 ECONNREFUSED / connection refused 目标地址与端口，以及对应服务是否监听 服务运行，但连接探测失败 地址、端口、认证及相关错误；不要把“进程存在”当成连通成功 终端 CLI 与后台服务表现不同 两者使用的 OpenClaw/Node 路径、版本和配置来源是否一致 openclaw doctor 可以提供诊断信息。遇到修复、迁移或重启提示时，先读清楚将改变什么；doctor --fix 和 gateway restart 是会修改状态的操作，应在问题范围明确后使用。\n模型请求与浏览器连接分别验证 Gateway 可连接，仍不等于模型请求成功。选择你自己的模型配置完成一次不含敏感内容的简单请求，再依据日志区分认证失败、提供商配额、模型名称或网络问题。401、403、429 应结合具体提供商的错误正文解释。\n浏览器连接则按任务选择资料目录与连接模式：\n1 openclaw browser --browser-profile openclaw status 上面检查的是独立托管浏览器。需要复用现有登录态时，按浏览器三种模式选择 user 或 chrome 并完成各自授权。网页能打开、扩展已安装、附加到正确标签页是不同的检查点。\n记录足够的信息再反馈 保留系统与版本、运行命令、实际地址的非敏感部分、错误时间和对应日志片段。删除令牌、密钥、Cookie 和个人会话内容。\n普通 JSON 示例可用JSON 工具检查；两份经过脱敏的示例可用文本 Diff比较。OpenClaw 的完整配置可能是 JSON5，应使用其自身诊断功能，不用普通 JSON 格式化器改写完整配置。\n参考 OpenClaw 官方排障指南 安装与运行时要求 浏览器模式 OpenClaw 2026.9.2 包信息 ","description":"从一次 Node.js 版本拦截的实际输出出发，分层检查 OpenClaw 命令、Gateway、模型请求与浏览器连接。","permalink":"https://blog.codeglimpse.top/p/openclaw-troubleshooting/","tags":["OpenClaw"],"title":"OpenClaw 装好了却用不了：从运行时到 Gateway 排查"},{"content":"pip install 显示成功，运行程序却出现 ModuleNotFoundError，首先需要回答的是：安装包和运行程序，用的是同一个 Python 吗？\n下面的例子使用 Windows、Python 3.13.2 和两个独立虚拟环境。重点是找到实际解释器的路径，这个方法也适用于其他 Python 3 版本。\n先看命令指向哪里 在运行程序的同一个 PowerShell 窗口中执行：\n1 2 3 4 Get-Command python, py, pip -All python --version python -c \u0026#34;import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix)\u0026#34; python -m pip --version Get-Command 显示命令解析结果；sys.executable 显示真正运行的解释器；python -m pip 让这个解释器加载自己的 pip。仅比较版本号不够，同一个版本也可以存在于多个目录。\n在本机，python 指向 D:\\JDKs\\Python3.13\\python.exe，旧版 py 启动器的列表同时包含普通版 3.13、自由线程版 3.13t 和 2.7。py 的默认条目还是 3.13t。因此，直接输入 py 与输入 python 并不一定选择同一套运行时。\n旧启动器可用 py --list-paths 查看条目；新版 Python Install Manager 使用 py list。先根据帮助输出判断自己用的是哪一种，再选择明确的版本，例如 py -3.13。安装方式见Python 安装教程。\n一次环境错位的实际复现 我在隔离目录创建了 env-a、env-b，并制作了一个名为 blog-env-demo 的本地演示包。它只提供一个字符串，用来验证包安装在哪个环境；它不是需要你从 PyPI 下载的依赖。\n两个环境都是 Python 3.13，pip 输出也都是 24.3.1，但路径分别落在各自的目录中。下列输出把实验目录统一缩写为 \u0026lt;实验目录\u0026gt;：\n1 2 3 4 5 env-a: pip 24.3.1 from \u0026lt;实验目录\u0026gt;\\env-a\\Lib\\site-packages\\pip (python 3.13) env-b: pip 24.3.1 from \u0026lt;实验目录\u0026gt;\\env-b\\Lib\\site-packages\\pip (python 3.13) 只给 A 安装演示包后，A 可以导入，B 则报错：\n1 2 3 4 5 .\\env-a\\Scripts\\python.exe -c \u0026#34;import blog_env_demo; print(blog_env_demo.MARKER)\u0026#34; # installed in this interpreter .\\env-b\\Scripts\\python.exe -c \u0026#34;import blog_env_demo\u0026#34; # ModuleNotFoundError: No module named \u0026#39;blog_env_demo\u0026#39; 随后，用 B 自己的解释器执行 -m pip，把同一个本地 wheel 装入 B，B 的导入也成功了。整个过程中没有重装 Python，也没有改全局 PATH。报错来自环境错位。\n在自己的项目中怎么修正 先确定项目实际使用的解释器。已有 .venv 时，可以直接检查它：\n1 2 .\\.venv\\Scripts\\python.exe -c \u0026#34;import sys; print(sys.executable)\u0026#34; .\\.venv\\Scripts\\python.exe -m pip --version 如果这是尚未创建虚拟环境的新项目，再用已安装的目标版本创建环境：\n1 py -3.13 -m venv .venv 在提供了 requirements.txt 的项目中，让安装和运行使用同一路径：\n1 2 .\\.venv\\Scripts\\python.exe -m pip install -r requirements.txt .\\.venv\\Scripts\\python.exe app.py 将版本号、依赖文件和入口文件替换为项目实际使用的值。IDE、调试器、定时任务也应选同一个解释器。直接调用 .venv 中的 Python 不要求先运行激活脚本，因此也不必为此修改 PowerShell 执行策略。\n路径一致后，还需要检查什么 现象 下一步 安装名和导入名不同 查包的使用文档，例如安装 Pillow 后导入的是 PIL 报错指向项目内的同名文件 检查是否用 json.py、requests.py 等文件名遮蔽了真正的模块 pip 有包，IDE 仍报错 查看 IDE 当前运行配置中的解释器路径，而不只看终端状态 自由线程版与普通版混用 核对运行时及二进制扩展支持情况，不直接复制另一个环境的 site-packages sys.prefix != sys.base_prefix 通常表示当前解释器处于虚拟环境。最终应以实际运行程序的解释器和完整错误为准。\n参考 Python：venv 虚拟环境 Python：Windows 上的 Python pip：用户指南 ","description":"用两个 Windows 虚拟环境复现 ModuleNotFoundError，定位 python、py 和 pip 指向不同环境的问题。","permalink":"https://blog.codeglimpse.top/p/python-environment-mismatch/","tags":["Python"],"title":"Python 装了包却无法导入：先确认解释器和 pip"},{"content":"Fail2ban 根据日志中的失败事件执行封禁动作。它能补充 SSH 等服务的防护，但需要正确的日志来源、过滤器和防火墙动作；安装服务本身不等于已经保护所有入口。\n适用范围与安装 下面以使用 systemd 的 Debian/Ubuntu 软件包环境和 SSH 为例。先核对发行版、SSH 实际端口及 Fail2ban 软件包版本；Fedora、RHEL 和其他发行版的仓库与日志配置不能直接套用。\n1 2 3 sudo apt update sudo apt install fail2ban fail2ban-client --version 优先使用发行版维护的软件包。确需源码安装时，按上游说明选择版本，并确认依赖、服务文件和后续升级方式。\n先确认 SSH 日志在哪里 Ubuntu/Debian 常见服务单元为 ssh，其他环境可能是 sshd。检查实际单元及日志：\n1 2 sudo systemctl status ssh --no-pager sudo journalctl -u ssh -n 30 --no-pager 如果使用文件日志，先确认 /var/log/auth.log 等文件确实存在且包含 SSH 认证事件。不要仅因为某篇教程写了该路径，就假定机器正在向它写日志。\n用小型覆盖文件配置 SSH jail 保留发行版的 jail.conf，在 /etc/fail2ban/jail.d/sshd.local 中写入需要覆盖的参数，避免复制整份默认配置后长期失去上游更新。\n启用前先确保有第二条管理会话或控制台，并将确认过的固定管理地址加入 ignoreip。下面只列出回环地址；它不包含你的远程管理地址。\n1 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 配置检查通过后，再启用或重新加载服务：\n1 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 已启用、日志来源正确，并检查实际的封禁动作。需要测试封禁时，使用受控测试来源并保留恢复入口，不要反复用唯一管理连接试错。\n封禁、解禁与持久化 下面的 192.0.2.10 是文档示例地址，操作前替换为经过核实的目标：\n1 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。因此不能笼统地说“重启后所有封禁都会失效”；恢复结果还受数据库、封禁剩余时间、清理策略和发行版配置影响。应检查当前有效配置和服务重启后的实际状态。\n扩展到其他服务前 不要只添加一个不存在过滤器的 nginx-404 jail。先确认过滤器文件、真实日志格式和误报范围，再用 fail2ban-regex 对受控样例验证。JavaScript 正则工具也不能替代 Fail2ban 自身的过滤器测试。\n如果没有封禁事件，按“日志是否产生 → 后端是否读取 → 过滤器是否匹配 → 防火墙动作是否成功”的顺序排查。修改配置后先运行 fail2ban-client -t，不要靠反复重启猜测原因。\n官方依据 Fail2ban 项目与安装说明 默认 jail 配置与后端说明 默认数据库与服务配置 ","description":"Fail2ban 是一款强大的工具，可以保护你的服务器免受暴力破解攻击。本教程将指导你如何安装和配置 Fail2ban。","permalink":"https://blog.codeglimpse.top/p/%E4%BF%9D%E6%8A%A4-linux-%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%9A%84%E4%B8%80%E5%A4%A7%E5%88%A9%E5%99%A8fail2ban/","tags":["Linux"],"title":"保护 Linux 服务器的一大利器：Fail2ban"},{"content":"OpenClaw 提供三种浏览器模式：隔离的 openclaw、基于 Chrome DevTools MCP 的 user，以及基于 Chrome 扩展的 chrome。它们主要区别在于是否复用个人登录态，以及连接时需要怎样的授权。\n先选择连接模式 配置名 连接对象 适合的情况 openclaw OpenClaw 管理的独立浏览器资料目录 自动化练习、测试，不需要个人浏览器登录态 user 通过 Chrome DevTools MCP 附加到已运行的浏览器 需要现有登录态，且有人在电脑前确认连接 chrome 通过 OpenClaw Chrome 扩展连接浏览器 需要现有登录态并已完成扩展安装、配对 独立浏览器是默认选择。两种复用登录态的方式都会扩大自动化能访问的内容，选择时应以任务需要和浏览器权限为准。\n使用独立托管浏览器 在 Gateway 已可用的前提下：\n1 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 这组命令可以分别核对状态、启动浏览器、打开测试网页和读取快照。仅命令退出成功，不能替代实际页面和快照结果的检查。\n使用 user 连接已有 Chrome user 模式要求目标 Chromium 浏览器为 144+，并启用远程调试。\n保持目标 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；标签页列表与快照还应对应实际浏览器。\nBrave、Edge 或其他资料目录可能需要显式设置 userDataDir；已经用调试端口启动的浏览器可能需要 cdpUrl。这些属于不同连接条件，按官方已有会话说明配置。\nChrome 扩展仍是支持的方式 当前官方扩展入口为：\n1 openclaw browser extension install 然后依照扩展文档完成安装、授权和配对。macOS/Linux 的本地主机引导与 Windows 的手动配对流程不同，请选择对应系统的步骤。\n完成配对后，使用 chrome 配置检查连接：\n1 2 openclaw browser --browser-profile chrome status openclaw browser --browser-profile chrome tabs 排查顺序 没有 browser 子命令：核对 OpenClaw 版本和浏览器插件是否启用。 无法附加 user：核对浏览器版本、远程调试开关、授权提示和目标资料目录。 状态正常但看不到目标页面：先确认使用了正确的 profile，再检查 tabs 返回内容。 扩展无法连接：检查当前操作系统对应的安装和配对流程，不能用 MCP 的调试开关代替扩展配对。 官方依据 Browser：模式、CLI 和已有会话 Chrome extension：安装与配对 ","description":"区分 OpenClaw 托管浏览器、Chrome DevTools MCP 和 Chrome 扩展，按任务选择连接方式并检查结果。","permalink":"https://blog.codeglimpse.top/p/openclaw-chrome/","tags":["OpenClaw"],"title":"OpenClaw 浏览器三种模式：托管、MCP 与 Chrome 扩展"},{"content":"OpenClaw 可以在自己的设备上运行 Gateway，并连接聊天渠道和模型服务。本篇按“检查环境 → 选择安装方式 → 初始化 → 验收”的顺序整理官方 CLI 流程。\n先检查适用环境 官方安装页列出的 Node.js 范围为 22.22.3+、24.15+ 或 25.9+，推荐 Node 26。Windows 用户可以选择原生 Windows Hub、PowerShell CLI 或 WSL2；这里主要介绍 CLI。\n先记录实际版本，再选用对应命令：\n1 2 node --version npm --version 模型认证方式取决于提供商。按照初始化向导在自己的设备上完成认证，不把密钥写进截图、分享链接或问题报告。安装器、初始化和守护进程步骤会改变本机环境。\n方式一：通过包管理器安装 使用 npm 12 或 npm 11.16+ 时，官方当前命令显式允许 OpenClaw 自身的安装脚本：\n1 npm install -g openclaw@latest --allow-scripts=openclaw npm 11.15 及更早版本不支持上述选项，使用：\n1 npm install -g openclaw@latest 如果使用 pnpm，当前官方全局安装方式为：\n1 pnpm add -g --allow-build=openclaw openclaw@latest pnpm approve-builds -g 不是当前支持的全局安装流程。latest 会变化；需要复现时，应先确认具体发布版本，再将其替换为明确版本号并记录 Node、包管理器和操作系统版本。\n方式二：使用官方安装脚本 脚本可能安装或切换 Node.js、安装 OpenClaw 并启动向导。先下载并阅读，再决定是否执行；有发布方校验信息时一并核对。\nmacOS / Linux / WSL2 1 2 3 4 5 installer_path=\u0026#34;$(mktemp)\u0026#34; curl -fL https://openclaw.ai/install.sh -o \u0026#34;$installer_path\u0026#34; less \u0026#34;$installer_path\u0026#34; # 审阅完成后执行 bash \u0026#34;$installer_path\u0026#34; Windows PowerShell 1 2 3 4 5 $installerPath = Join-Path $env:TEMP \u0026#39;openclaw-install.ps1\u0026#39; Invoke-WebRequest -Uri \u0026#39;https://openclaw.ai/install.ps1\u0026#39; -OutFile $installerPath Get-Content -LiteralPath $installerPath # 审阅完成后执行 \u0026amp; $installerPath 本篇使用官方 OpenClaw 发行版。第三方分支、国内镜像可能采用不同的包名、配置和版本，应按其各自文档安装。源码构建请按官方安装页对应版本的 pnpm 要求操作。\n初始化和验收 如果安装器尚未运行初始化向导：\n1 openclaw onboard --install-daemon 该命令会配置模型、Gateway 和后台启动方式。完成后分别检查 CLI 和服务：\n1 2 3 4 openclaw --version openclaw doctor openclaw gateway status openclaw dashboard doctor 是诊断入口，某些版本可能提示迁移或修复配置；先阅读输出再接受变更。能输出版本号不等于 Gateway 已运行，打开 Dashboard 也不等于已经完成一次模型请求。\n常见失败与下一步 找不到 openclaw：重新打开终端，检查 npm prefix -g 和命令搜索路径，确认使用的是安装时的 Node 环境。 安装脚本未获允许：先核对 npm/pnpm 版本和上面的许可选项，不要批量允许不认识的包。 Gateway 未运行：查看 openclaw gateway status 的服务与连接信息，再按官方排障页定位。 下一篇介绍浏览器的三种连接方式。普通 JSON 示例可以用本站 JSON 工具检查语法；完整 JSON5 配置仍应由 OpenClaw 自身诊断。\n官方依据 安装与系统要求 入门与初始化 版本发布记录 ","description":"按官方资料检查 Node.js 与包管理器要求，选择安装方式、初始化并验证 OpenClaw Gateway。","permalink":"https://blog.codeglimpse.top/p/openclaw-install/","tags":["OpenClaw"],"title":"OpenClaw 安装与配置：环境检查与验收"},{"content":"卸载 OpenClaw 涉及不同范围：Gateway 服务、状态目录、工作区、桌面应用和 CLI 包。先确定哪些内容需要保留，并确认备份，再开始清理。\n优先使用内置卸载器 CLI 仍可用时，先预览所有清理范围：\n1 openclaw uninstall --dry-run --all 核对实际目录和服务后，进入交互式卸载：\n1 openclaw uninstall 当前官方交互流程初始只选中 Gateway 服务，状态、工作区和应用是独立选项；--all 会选择全部四项。删除状态不等于删除配置过的工作区。服务移除失败时，相关数据范围可能被保留，并报告部分清理失败。\n如果 CLI 已删除但后台服务仍在，按官方手动移除说明处理对应操作系统的服务，不要终止所有 Node.js 进程。\n下面的附带脚本只负责范围更窄的包、进程和 Docker 资源盘点及清理，不能替代内置卸载器对服务、状态和工作区的处理。\n自动化卸载脚本（先检查，再执行） 清理脚本默认只做 dry-run（只读盘点），列出检测到的 OpenClaw 全局包、命令行明确包含 OpenClaw 的 Node.js 进程，以及当前 Docker 上下文中名称或镜像明确匹配 OpenClaw 的资源。脚本不会停止全部 Node.js 进程，也不会扫描或删除用户目录、配置文件、注册表或任意 Docker 资源。\n不要使用 curl | bash 或 irm | iex 直接执行远程脚本。请先下载、核对 SHA-256、阅读内容，再运行 dry-run。确认清单无误后使用 -Apply/--apply；交互模式还会要求输入 REMOVE OPENCLAW。\nWindows（PowerShell） 1 2 3 4 5 6 7 8 9 10 11 12 $scriptUrl = \u0026#39;https://blog.codeglimpse.top/post/openclaw-uninstall/CleanupOpenClawForWindows.ps1\u0026#39; $scriptPath = Join-Path $env:TEMP \u0026#39;CleanupOpenClawForWindows.ps1\u0026#39; Invoke-WebRequest -Uri $scriptUrl -OutFile $scriptPath $expectedSha256 = \u0026#39;eab731bd073f42fb75569be6c1dd3af37aca3214957057241ed13072fcc40daa\u0026#39; if ((Get-FileHash -Algorithm SHA256 -LiteralPath $scriptPath).Hash.ToLowerInvariant() -ne $expectedSha256) { throw \u0026#39;SHA-256 校验失败，请勿执行该文件。\u0026#39; } Get-Content -LiteralPath $scriptPath \u0026amp; $scriptPath # dry-run，只读盘点 \u0026amp; $scriptPath -Apply # 查看同一清单并要求明确确认后执行 通常不需要管理员权限；只有当前安装位置或 Docker 环境本身要求提升权限时，才应使用管理员终端。-Apply -Yes 仅用于你已经审核过清单的受控自动化环境。\nLinux（Bash） 1 2 3 4 5 6 7 script_path=\u0026#34;$(mktemp)\u0026#34; curl -fL \u0026#39;https://blog.codeglimpse.top/post/openclaw-uninstall/CleanupOpenClawForLinux.sh\u0026#39; -o \u0026#34;$script_path\u0026#34; printf \u0026#39;%s %s\\n\u0026#39; \u0026#39;0cfab4f8823a1644ef2e5b47275b144417c271372b7b11b795cf8c60a6689cb8\u0026#39; \u0026#34;$script_path\u0026#34; | sha256sum -c - less \u0026#34;$script_path\u0026#34; bash \u0026#34;$script_path\u0026#34; # dry-run，只读盘点 bash \u0026#34;$script_path\u0026#34; --apply # 要求输入 REMOVE OPENCLAW 后执行 macOS（Bash） 1 2 3 4 5 6 7 script_path=\u0026#34;$(mktemp)\u0026#34; curl -fL \u0026#39;https://blog.codeglimpse.top/post/openclaw-uninstall/CleanupOpenClawForMacOS.sh\u0026#39; -o \u0026#34;$script_path\u0026#34; printf \u0026#39;%s %s\\n\u0026#39; \u0026#39;a7e6048a20a933e4297edfe64847afc8f5a206add153502ff6ac260be9d7a801\u0026#39; \u0026#34;$script_path\u0026#34; | shasum -a 256 -c - less \u0026#34;$script_path\u0026#34; bash \u0026#34;$script_path\u0026#34; # dry-run，只读盘点 bash \u0026#34;$script_path\u0026#34; --apply # 要求输入 REMOVE OPENCLAW 后执行 卸载 CLI 包并验收 处理完所选服务和数据范围后，使用当初安装它的包管理器卸载 CLI。下列命令按实际情况选择一种：\n1 2 3 4 5 # npm 安装 npm uninstall -g openclaw # pnpm 安装 pnpm remove -g openclaw openclaw-cn 等第三方分支应单独确认。按实际包前缀和已审核清单处理残留，不照抄猜测的全局安装路径直接删除。随后检查原服务和命令搜索结果；仅 CLI 命令消失不能证明后台服务已经移除。\n常见问题 权限不足时，先确认安装位置或 Docker 环境的实际要求，不统一使用管理员权限处理所有清理步骤。\n找不到命令时，核对当初安装使用的 PATH 和包管理器环境；脚本清单只覆盖实际检测到的范围。\ndry-run 只报告计划，实际完成情况还要检查执行结果、剩余服务与资源。\n官方依据 OpenClaw 卸载范围、预览与手动服务移除\n","description":"本文提供了在 Windows、Linux 和 macOS 系统上彻底卸载 OpenClaw 的详细步骤和自动化脚本。","permalink":"https://blog.codeglimpse.top/p/%E5%A6%82%E4%BD%95%E5%BD%BB%E5%BA%95%E5%8D%B8%E8%BD%BD-openclaw-%E5%B0%8F%E9%BE%99%E8%99%BE/","tags":["OpenClaw"],"title":"如何彻底卸载 OpenClaw 小龙虾"},{"content":"先选择适合项目的 Python 版本，再确认实际执行的解释器，最后为项目创建虚拟环境。以下介绍 Python 3.14 的安装方式；独立安装器的截图展示的是 3.12/3.13 界面。\nWindows：优先了解 Python Install Manager 官方目前推荐从 python.org 或 Microsoft Store 获取 Python Install Manager。它与旧版独立 .exe 安装器及旧 py 启动器需要区分；遇到命令冲突时先查看官方 Windows 文档。\n安装管理器后，在 PowerShell 中确认可用命令，再安装所需版本。以下以 3.14 为例，实际项目仍需检查依赖兼容性：\n1 2 3 4 5 py help py install 3.14 py list py -3.14 --version py -3.14 -c \u0026#34;import sys; print(sys.executable)\u0026#34; 管理器会下载运行时。Python 3.14 的 Windows 支持范围见官方说明；不要把旧系统支持和当前受维护系统混为一谈。\n已有 3.12/3.13 独立安装器时 旧界面仍可能在已有环境中出现。一般开发场景先选择当前用户安装；只有明确需要所有用户共用时，才选择系统范围安装并提升权限。py 启动器提供版本选择，不等于所有终端中的 python 都会指向同一个解释器。\n安装时保留 pip；调试符号、调试二进制和完整标准库测试套件是按需组件。PATH 和文件关联也应结合已有解释器决定，不要统一勾选全部选项。\n静默安装必须使用已经下载并核对的具体安装器文件名。例如，下面的参数用于旧安装器的当前用户安装：\n1 2 # 将文件名替换为已核对的安装包 ./python-3.13.7-amd64.exe /quiet InstallAllUsers=0 PrependPath=1 Include_test=0 这里的文件名仅演示旧安装器语法，不表示 3.13.7 是推荐下载的最新补丁版本。3.14 文档已将完整安装器列为弃用方式，新环境应先评估安装管理器。\nmacOS 使用官方安装包 从 Python for macOS 下载与你的 macOS 和处理器兼容的安装包，阅读安装器中的支持范围与许可说明。\n安装完成后，按当前安装器说明运行对应版本目录中的 Install Certificates.command。它会联网安装该 Python 使用的证书组件。不要照抄旧截图中的版本目录。\n1 2 python3 --version python3 -c \u0026#34;import sys; print(sys.executable)\u0026#34; 不要删除或修改 Apple 管理的 /usr/bin/python3。官方 Python 可以与系统开发工具使用的解释器并存。\n已使用 Homebrew 时 先查看 Homebrew 当前安装要求。其要求涉及受支持的 macOS、硬件和 Xcode Command Line Tools，不能概括为“必须先安装系统 Python”。\n在 Homebrew 已正常配置的终端中：\n1 2 3 4 brew --version brew install python python3 --version command -v python3 如果尚未安装 Homebrew，先按官网说明下载、审阅安装脚本再执行。出现路径冲突时先检查终端配置，不要直接强制覆盖链接。\nLinux：使用发行版软件包 Debian / Ubuntu 1 2 3 sudo apt update sudo apt install python3 python3-pip python3-venv python3 --version 安装 Python 不需要顺带升级整台机器、修改整个 ~/.local 的所有者或删除 APT 锁文件。遇到锁占用时，先确认另一个包管理任务是否仍在运行，等待完成或按发行版的故障处理流程排查。\nFedora 1 2 sudo dnf install python3 python3-pip python3 --version RHEL 及其他发行版的软件包版本和仓库策略不同，应按对应发行版文档选择。不要替换系统 Python，也不要默认使用 sudo pip 安装项目依赖。\n为每个项目创建虚拟环境 在项目目录中执行。Windows 示例明确使用已安装的 3.14：\n1 2 3 py -3.14 -m venv .venv .\\.venv\\Scripts\\python.exe --version .\\.venv\\Scripts\\python.exe -m pip --version macOS / Linux：\n1 2 3 python3 -m venv .venv .venv/bin/python --version .venv/bin/python -m pip --version 直接调用虚拟环境中的解释器即可，不必为了运行示例而修改 PowerShell 执行策略。安装依赖时沿用同一个解释器的 -m pip。\n验收与常见问题 记录操作系统、--version 输出、sys.executable 和 pip --version，确认它们属于预期环境。 python 打开商店或版本不对：检查应用执行别名、py list 与 PATH。 提示 externally-managed-environment：为项目创建虚拟环境，不绕过发行版保护。 缺少 venv/ensurepip：安装发行版对应的虚拟环境组件，再重新创建环境。 官方依据 Python on Windows Python on macOS venv 虚拟环境 Homebrew 安装要求 ","description":"一站式详解 Windows、macOS 及 Linux 系统下的 Python 多种安装方案","permalink":"https://blog.codeglimpse.top/p/python-install/","tags":["Python"],"title":"Python 下载与安装教程"}]