给 sing-box 提交 XHTTP 实现后 PR 被关闭且账号被 Block，想请教是哪里做错了

先说明一下，发这个帖子不是想挂人，也不是要求项目必须合并我的代码。

我只是第一次遇到这种情况：花时间实现了一个功能、补测试和文档、修完 CI ，随后 PR 在没有任何评论的情况下被关闭，之后发现 自己的 GitHub ID 似乎也被该项目 Block 了。

因为没有收到原因，所以想把时间线和技术背景完整写出来，请有开源项目维护经验的 V 友帮我看看，问题可能出在哪里。

项目：SagerNet/sing-box PR： https://github.com/SagerNet/sing-box/pull/4326 PR 标题：feat(xhttp): add XHTTP transport

时间线：

1. 7 月 17 日开始实现 sing-box 的 XHTTP transport 。

2. 7 月 22 日 14:34 左右整理并提交主要实现，包括：

   • XHTTP 客户端和服务端
   • stream-one 、stream-up 、packet-up 等模式
   • HTTP/1.1 、HTTP/2 、h2c
   • Xray 兼容配置字段
   • xmux 、padding 、download settings 等功能

3. 14:35 左右补充生命周期测试、协议测试以及与外部 Xray-core 可执行文件的互操作测试。

4. 14:37 创建 PR #4326 。

5. PR 创建后发现 CI/Lint 有格式问题，于是根据 CI 输出修正并重新推送。

6. 14:58 推送 lint 修复。之后 GitHub Actions 中 Linux 、Windows 、macOS 、Android 各平台的 Lint 和 Test 都通过了。

7. 15:23 ，PR 被项目维护者直接关闭。

8. PR 页面没有 review 、没有 comment ，也没有说明不接受该功能的原因。之后我发现自己的账号似乎也无法再与该项目正常互动， 表现像是被 Block 。

这里也把可能有争议的技术背景说清楚。

XHTTP 最初来自 Xray-core 。Xray-core 使用 MPL 2.0 ，sing-box 使用 GPLv3-or-later 。

我的实现参考过 Xray-core 的公开源码和协议行为，并不是严格意义上的 clean-room implementation 。这一点我愿意如实披露。

但实现本身使用的是 sing-box 的 Dialer 、TLS 、transport handler 和 Go net/http 架构，没有导入或链接 Xray-core 。互操作测 试也是把 Xray 当成外部程序运行。

事后检查新增代码和 Xray splithttp 源码，没有发现明显的连续代码块复制。不过我确实在 config.go 里写过一句：

“The implementation is independent from Xray-core.”

现在回头看，这句话不够准确。虽然代码是按 sing-box 架构重新实现的，但既然开发时阅读和参考过 Xray 源码，就不应该把它描述 成完全独立或 clean-room 。我愿意修改这句话，也愿意根据要求补充来源说明、版权声明或 MPL 文件级许可信息。

据我目前查到的资料，MPL 2.0 是文件级 copyleft ，而且在没有 Exhibit B 排除的情况下可以通过 MPL 2.0 §3.3 与 GPLv3 项目组 合。也就是说，即使部分文件被认定为 Xray 的派生实现，通常也应该是对相关文件补充 MPL 来源和许可义务，而不是整个 sing-box 被“污染”。

当然，许可证理解如果有错误，也欢迎指出。

我能想到 PR 被拒绝的原因包括：

• 上游根本不准备支持 XHTTP ；
• PR 体量太大，提交前应该先开 issue 讨论；
• 维护者不接受参考其他项目源码的实现；
• 对代码来源、AI 辅助或许可证存在疑虑；
• 实现方式不符合项目方向；
• 我之前的 “independent” 表述让维护者对来源产生了不信任；
• 还有我没有注意到的社区规则或历史问题。

这些理由中的任何一个，如果维护者明确说明，我都可以理解：项目是维护者的，他们当然没有义务合并任何 PR 。

我真正困惑的是，在 CI 已经通过、PR 没有争吵、没有 review 对话的情况下，为什么会直接关闭并疑似 Block ，而没有留下一句原 因。

所以想请教大家：

1. 阅读其他 MPL 2.0 项目的源码后，使用 GPL 项目自身架构重新实现兼容协议，通常应该怎样声明来源？

2. 这种规模的功能是否应该先开 issue ，得到维护者确认后再实现？

3. PR 中那句 “independent from Xray-core” 是否严重到足以让维护者直接失去信任？

4. 从维护者角度看，还有哪些常见原因会导致无评论关闭 PR 并 Block 提交者？

再次说明，我发帖不是要求维护者必须合并，也不希望大家去 PR 下留言或打扰项目。

如果确实是我的提交方式、来源说明或者许可证处理有问题，我愿意承认并改正。我只是希望弄明白原因，避免以后再次踩同样的坑。