企业官网建设流程全解析

NotProton 是一个让 macOS 版 Steam 启用 Steam Play（Proton 兼容层）的开源工具，它采用GPL-3.0 主导的混合许可模型，并内置了一套从下载校验到构建绑定的完整安全实践。本文面向新手，带你快速看懂 NotProton 的授权结构、关键安全设计，以及如何以贡献者身份参与这个 macOS 游戏化项目。

一、许可结构：GPL-3.0 主导的混合授权模型 📜

NotProton 的许可情况属于典型的"多来源项目"：主体代码自由开源，来自 Valve 的部分则遵循 Valve 的原始授权。官方在 NOTICE 文件中对此做了明确说明。

对新手意味着什么？

• 你可以自由查看、修改和分发 NotProton 主体代码，但分发时需保留 GPL-3.0 的相应条款；
• 修改或再分发lsteamclient、steam-shim等 Valve 衍生部分时，须遵守 Steamworks SDK License 与 BSD-3-Clause 的条件；
• 字体资源（如 fonts/ume/、fonts/noto/）各有独立许可，打包发布前建议单独确认。

💡 简单记忆："谁的代码，谁说了算"。NotProton 通过把每份第三方代码配上独立的 LICENSE 文件，让授权边界一目了然。

二、安全工程实践：从下载校验到构建绑定 🔒

NotProton 需要修改 Steam 客户端并下载 Valve 的二进制文件，这类项目天然敏感。它的工程实践中有四个值得新手学习的安全设计。

2.1 SHA-256 固定下载（Pinned Download）

App 从 Valve CDN 拉取文件时，不是"下载什么就执行什么"，而是先下载、后比对 SHA-256 摘要，只有完全匹配才会落盘。相关实现位于：

• PinnedDownload.swift：从多个 CDN 主机逐个尝试，任何"主机返回的哈希不符"都会记为mismatch并跳过；
• Digest.swift：分块计算文件 SHA-256，避免大文件一次性载入内存。

若所有主机都返回错误哈希，程序会提示"下载文件有问题，请检查 NotProton 更新"——这是一种典型的供应链完整性防护。

2.2 载荷清单：只安装"列在名单上"的文件

应用安装的二进制文件全部登记在 payload.manifest 中，按来源分为built（自编译）、patched（打过补丁的 ntdll）、valve（Valve 原版）三类，解析逻辑见 PayloadManifest.swift。

配套的 bridge/verify.sh 脚本会用同一份清单核对磁盘上的文件是否"多了或少了"：

./verify.sh # 列出缺失和多余的文件 ./verify.sh --prune # 顺带把多余文件移到回收目录

这意味着即使安装流程中途出错，你也能用一条命令验证本机部署状态是否与清单一致。

2.3 签名库与 Steam 构建版本绑定

NotProton 注入 Steam 进程的方式依赖"字节签名"（AOB）。为了避免对错误版本的 Steam 误打补丁，签名数据库文件按 Steam 客户端构建号命名存放于 signatures/macos.arm64/，且加载时会校验steam_build字段（见 sigdb.h）。

配合 README.md 中声明的支持版本（stable1792618285/ beta1792626604），形成了"版本未验证 → 签名不匹配 → 拒绝操作"的防误伤链条。

2.4 受控的更新与分发

• 应用更新走 AppUpdater.swift 封装的Sparkle 框架（MIT 许可），仅在正式构建中启用定时检查；
• 官方提供了 Homebrew Cask 分发渠道：brew install --cask notprotonnot/notproton/notproton；
• 文件并发访问使用 FileLock.swift 的flock锁，防止多进程同时修改运行环境。

三、可复现的构建与验证体系 🛠️

项目顶层 Makefile 负责编译 dylib 注入组件，app/目录则由 Swift Package 管理（见 app/Package.swift）。几个值得注意的细节：

• 编译参数统一启用-Wall -Wextra与可用性检查告警，-std=c11级别的代码规范要求清晰；
• dylib/tests/下有大量轻量验证脚本（如 buildcheck.sh、sigcheck.py、bridgecheck.sh），分别覆盖函数提取、签名数据库解析、桥接文件一致性等场景；
• Package.swift 特意处理了"未构建的检出仓库"：声明的资源若缺失会直接构建失败，避免用户拿到一个"看起来能跑但缺少载荷"的安装包。

四、社区协作：如何向 NotProton 贡献代码 🤝

CONTRIBUTING.md 的开头就强调了一句话："不要让这份文档成为你贡献的障碍"——作者宁愿要一个不完美但可加工的 PR，也不要什么都没有。核心约定可以归纳为五点：

1. PR 描述尽量手写：翻译没问题，但作者明确表示人类写的文字比机器生成的更容易阅读；
2. 开 PR 前先查历史：搜索已关闭的 PR，避免重复劳动。部分功能（如支持 CrossOver 以外的 Wine 运行时）不是项目目标；
3. 注释风格偏好：短注释，只在复杂处插入，且尽量是人类手写而非 AI 生成；
4. 评审是人工深度评审：作者会花一整天时间逐行理解 PR 的逻辑、测试边界情况（多 Steam 账户、多游戏库、多 macOS 用户、不同文件系统），首次贡献者的 PR 可能会有等待；
5. 重写不代表否定：触及复杂区域的 PR 可能被大幅改写，但作者会把作者署名保留给原提交者。

新手上手三步走

第 1 步：获取源码

git clone https://gitcode.com/gh_mirrors/no/NotProton

第 2 步：熟悉目录分工（README.md "Developer Notes" 部分）

第 3 步：选择低风险切入点

• 先从app/的 UI、本地化（Localizable.xcstrings）或测试用例入手；
• 修改涉及 Steam 进程内注入、前缀（prefix）管理的部分前，先在 issue 区或 PR 描述中说明你的思考；
• 引入新测试时，参考 Tests/NotProtonAppTests/ 的现有写法保持风格一致。

五、给新手的贡献自检清单 ✅

提交 PR 前，可以对照 CONTRIBUTING.md 检查一遍：

• 我搜索过历史 PR，确认不是重复劳动；
• PR 描述是手写的人类文字，讲清了"改了什么、为什么"；
• 注释简短、只在复杂处出现，能帮助他人理解逻辑；
• 我考虑过改动在多账户、多游戏库、不同文件系统下的表现；
• 若触及复杂模块，我已在描述中标注"这需要进一步工作"并愿意接受改写。

结语

NotProton 展示了开源项目工程化的完整侧面：用 NOTICE + 分层 LICENSE 厘清混合授权，用 SHA-256 固定下载与清单校验守住供应链安全，用签名库版本绑定防止误伤，再用一份坦诚、低门槛的贡献指南吸引社区参与。无论你是想读懂它、修改它，还是给它提第一个 PR，这些实践都值得作为参考。让我们共同参与，让 Mac 的游戏体验更好。