从使用边界到转发接口：PharosVip 的客户端维护之路
维护 Pharos Pro，在公开手册、协议适配与上游协作之间留下可核对的工程记录
第一幕 · 名字之前，先辨认留下的记录
2018 年 9 月 28 日，Pharos 的项目频道发布了更名说明，测试入口仍保留 Shadow_X 的旧名字。这解释了产品早期称呼的来路，却不能单凭频道署名还原某一位开发者的全部经历。
可直接追到 PharosVip 项目的 Git 记录，从 2019 年 2 月 26 日的共享代理指南开始；3 月 7 日，Android 测试仓库留下根提交。两处起点都只是各自仓库当前保留的历史，不能替代整个客户端的诞生日期。
同年 5 月，PharosVip 向 V2Ray 手册提交产品介绍，明确链接到 App Store 中的 Pharos Pro。官方文档指向其 GitHub，账号主页又指回同一款应用，公开开发身份由这些具体关联相互印证。[3][5][6][4][2][1]
第三幕 · 从配置扩展，走到脚本接口
2023 年 11 月 29 日，Extension 仓库的根提交只有简短的“Extension in profile”。随后出现的配置示例，将重定向、拒绝、请求头和响应内容修改放进同一套公开说明。
2024 年 6 月 17 日，署名关联到 PharosVip 的提交“script manual”加入脚本参数手册：环境信息、本地键值存储、系统通知和 HTTP 请求，都有了可供使用者查阅的入口。
手册把 `$done()` 写为“中断请求返回”，又把 `$done({})` 写为“不对网络请求做任何处理”。相邻两种调用语义不同，使用者需要据此判断脚本何时结束、是否改写请求。
这里能够确认的是公开接口说明的演进。文档没有替代发行包验证，也不能证明某个旧版客户端已经具备后来列出的全部能力。[8][9][10]
第四幕 · 两个参数的顺序，一次有回应的协作
2024 年 8 月 7 日，PharosVip 提交的 ChaCha20 修改把问题收敛到构造函数的参数次序：调用端传入 key 与 salt，底层函数接收 nonce 与 key。补丁增加包装函数，在接口边界调整顺序。
他的提交说明写道：“Fix parameter order in ChaCha20 constructor and implement proper wrapping for encryption/decryption functions”。这是一处接口适配修正，不是新加密算法。
同日，维护者 wwqgtxx 回复“thanks, fixed in”，并链接到 Mihomo 的 030631607e26e7bfb3c1bc196cfb2bc46576d8f9 提交。该提交关联的作者也是 PharosVip，实际 diff 更新了两项 Shadowsocks 依赖。
原 PR 以未合并状态关闭，维护者另行指向修复记录。保留这两个事实，才能说明协作的实际结果，而不把 PR 关闭误写成原补丁直接合入。[11][12][13][14]
第五幕 · 回调返回之后，数据仍要有归属
2026 年 9 月 10 日，PharosVip 向 MetaCubeX/sing-tun 提交“support mipstack”。适配代码把用户态 IP 栈接入 TUN 读写与已有连接处理接口，并处理 TCP、UDP、ICMP 的交接。
9 月 11 日，后续提交将 ICMP 转发移出回调：先保存需要继续使用的数据，再通过有界队列交给独立处理流程；相应测试覆盖路由准备阻塞、队列饱和与异步数据持有。
随后，另一次提交改用 Detach 简化 ICMP 处理。这里的工程问题是回调生命周期与后续处理之间如何交接数据，不能由提交标题推算吞吐或能耗提升。
截至 2026 年 9 月 14 日，PR #25 仍未合并。它证明 PharosVip 正在参与这项上游适配，不证明上游已经发布，也不单独证明 Pharos Pro 商店版采用了其中实现。[15][16][17][18]
