| name | f8x-version-update |
| description | 批量检查和更新 f8x 中工具的版本号。当需要检查哪些工具有新版本、更新某个工具的版本、或批量更新版本时使用。即使用户只是说 "检查一下版本"、"xxx 更新了没"、"升级一下工具" 也应触发。 |
f8x 版本更新
f8x 中所有工具版本都硬编码在脚本顶部（行 93-435），每次上游发布新版本都需要手动更新。这个 skill 指导如何安全地完成版本更新。
检查流程
Step 1: 运行 check_releases.py
cd /Users/f0x/pte-project/infra-plat/f8x
python3 check_releases.py --file f8x --output diff.txt
脚本会扫描 f8x 中所有 # https://github.com/owner/repo 注释后面的 _Ver/_Version 变量，与 GitHub Releases API 对比，输出需要更新的工具列表。
输出格式：
owner/repo: v1.0.0 -> v2.0.0 (xxx_Ver) https://github.com/owner/repo/releases/tag/v2.0.0
环境变量：
GITHUB_TOKEN — 提高 API 速率限制（建议设置，否则 60 次/小时会很快用完）HTTP_PROXY / HTTPS_PROXY — 代理（脚本默认使用 --proxy http://127.0.0.1:7890，可用 --proxy "" 禁用）
Step 2: 人工筛选
不要盲目更新所有有新版本的工具。 逐个检查 diff.txt 中的工具，确认：
- 新 release 是否包含预编译二进制？ 有些项目发布 release 但只打了 tag 没有 assets，或者只有源码包。如果没有二进制，跳过
- 文件名格式是否变了？ 对比新旧 release 的 asset 文件名，如果命名规则变了（比如
_amd64 → -amd64），安装函数也要同步改
- 是否有 breaking changes？ 看 release notes，如果 CLI 用法变了可能需要调整安装函数
用 GitHub API 快速拿到 release assets 列表（比打开网页更快更准）：
curl -s https://api.github.com/repos/OWNER/REPO/releases/latest | python3 -c "
import json,sys
d=json.load(sys.stdin)
print(f'Tag: {d[\"tag_name\"]}')
for a in d.get('assets',[]): print(f' {a[\"name\"]}')"
如果 diff.txt 里有大量工具需要更新，逐个处理——每个工具走完 Step 2→3→4 的完整循环再开始下一个，不要一口气改完所有再验证，否则出错时很难定位是哪个工具改坏的。
Step 3: 逐个更新版本变量
确认要更新后，修改 f8x 脚本（行 93-435 区域）。
首先，用变量前缀搜索找出该工具的所有关联变量，确认要改几个：
grep "^httpx_" f8x
grep "^frp_" f8x
这一步能避免"只改了 _Ver 忘了改 _bin_*"的常见错误。
简单情况：只有 _Ver
xxx_Ver="v1.0.0"
xxx_Ver="v2.0.0"
常见情况：_Ver + 关联文件名变量
这是最容易出错的地方。文件名变量里嵌入了版本号，必须全部同步修改：
httpx_Ver="v1.8.1"
httpx_bin_amd64="httpx_1.8.1_linux_amd64.zip"
httpx_bin_arm64="httpx_1.8.1_linux_arm64.zip"
httpx_Ver="v1.9.0"
httpx_bin_amd64="httpx_1.9.0_linux_amd64.zip"
httpx_bin_arm64="httpx_1.9.0_linux_arm64.zip"
复杂情况：_Ver + _File_* + _Dir_*
某些工具（如 frp）解压后目录名也包含版本号：
frp_Ver="v0.67.0"
frp_File_amd64="frp_0.67.0_linux_amd64.tar.gz"
frp_File_arm64="frp_0.67.0_linux_arm64.tar.gz"
frp_Dir_amd64="frp_0.67.0_linux_amd64"
frp_Dir_arm64="frp_0.67.0_linux_arm64"
frp_Ver="v0.68.0"
frp_File_amd64="frp_0.68.0_linux_amd64.tar.gz"
frp_File_arm64="frp_0.68.0_linux_arm64.tar.gz"
frp_Dir_amd64="frp_0.68.0_linux_amd64"
frp_Dir_arm64="frp_0.68.0_linux_arm64"
Step 4: 验证
更新后做两件事：
- 语法检查：
bash -n f8x
- 搜索残留旧版本号：用旧版本号 grep 一下，确认没有遗漏
grep "1.8.1" f8x
关联文件名变量的命名模式
f8x 中关联变量的后缀没有统一标准，以下是实际存在的几种：
| 后缀模式 | 示例 | 含义 |
|---|
_bin_amd64 / _bin_arm64 | httpx_bin_amd64 | 完整文件名（最常见） |
_File_amd64 / _File_arm64 | frp_File_amd64, chisel_File_amd64 | 同上，另一种命名 |
_Install_amd64 | Nuclei_Install_amd64 | 同上，早期命名 |
_Dir_amd64 / _Dir_arm64 | frp_Dir_amd64 | 解压后的目录名 |
更新某个工具时，先搜索该工具的变量前缀找出所有关联变量：
grep "^httpx_" f8x
grep "^frp_" f8x
版本号格式注意事项
_Ver 变量通常带 v 前缀（v1.0.0），但文件名中一般不带（httpx_1.0.0_linux_amd64.zip）- 少数工具的
_Ver 不带 v（如 Adinfo_Ver="v0.3" 但 release tag 是 v0.3）
- 通过 GitHub Releases 页面的 asset 文件名来确认准确格式，不要猜
常见陷阱
- 只改了
_Ver 忘了改 _bin_*：下载时 404，因为文件名里还是旧版本号
- release 没有预编译文件：有些项目只打 tag 不发布 assets，或只有源码 tarball
- pre-release 版本：
check_releases.py 用的是 releases/latest API，不会返回 pre-release，但如果 fallback 到 tags 就可能拿到非稳定版
- 文件名格式变更：上游改了命名规则但没改功能，需要同步修改安装函数中的解压/移动逻辑
- Arsenal 也用了版本变量：如果工具在 Arsenal 里有 case 块，检查是否也需要更新
关键文件
| 文件 | 作用 |
|---|
/Users/f0x/pte-project/infra-plat/f8x/f8x | 主脚本，版本变量在行 93-435 |
/Users/f0x/pte-project/infra-plat/f8x/check_releases.py | 版本检查脚本 |
/Users/f0x/pte-project/infra-plat/f8x/f8x_version.sh | 版本覆盖（可选，用于测试） |
