企业官网建设流程全解析

px0 是一款专为审阅 AI 生成代码而打造的高性能代码审查 IDE：它以单个 Go 静态二进制运行，把浏览器变成零延迟的代码控制台，内置 Git/GitHub 集成、毫秒级工作区搜索与 AI 编程代理（coding harness）协作能力。这篇 px0 开发者指南将带你从零完成源码构建、测试运行与性能基准，并搞清楚参与 px0 贡献的正确姿势。

一、构建前准备：装好两样工具即可开工

px0 坚持"零运行时依赖"的设计原则——没有 Electron、没有 Node 运行时、没有 CGO。因此本地构建只需要两个工具：

克隆仓库：

git clone https://gitcode.com/gh_mirrors/px0/px0 cd px0

💡 整个仓库结构非常精简：根目录是 Go 服务端源码，web/是纯 JS/CSS 前端，docs/是完整文档——打开就能读。

二、一键源码构建：make build 背后的两步流程

px0 提供了功能齐全的 Makefile，直接运行：

make build

这一条命令实际串联了两个阶段（见 Makefile）：

1. 打包前端：执行node ./scripts/build-web.js，把 web/src/ 下 40 余个 ES 模块合并为单文件web/app.js；
2. 编译 Go 二进制：go build -trimpath -ldflags="-s -w" -o px0 .，前端资产通过go:embed内嵌进二进制。

最终产物就是一个几 MB 的无依赖静态文件，./px0 --version即可验证。

其余常用 make 目标一览：

如果你偏好容器化构建，仓库自带的 Dockerfile 采用三段式构建（Node 打包 → Go 静态编译 → Alpine 极简运行镜像），docker build即可得到可发布镜像。

三、本地调试：用 -dev 模式获得前端实时热加载

正式构建需要每次改完前端都重新跑make build。开发时建议改用开发模式：

go run . -dev .

-dev标志让服务器直接从磁盘读取web/下的原始模块文件，而不是内嵌的打包产物——这意味着你修改 web/src/ 里的任意 JS 或 CSS 后，刷新浏览器即可看到效果，无需重新构建，这对前端调试极其友好。

前端模块职责清晰，例如：web/src/state.js（全局状态）、web/src/renderer.js（虚拟滚动渲染）、web/src/tabs.js（标签页管理）、web/src/agent.js（AI 代理协作）。完整的模块地图可在 docs/agents/README.md 的"Frontend Architecture & Code Map"一节找到。

四、跑测试与基准：验证你的改动没有打破速度

px0 把速度当作核心卖点，所以测试覆盖非常扎实——几乎每个核心模块都有同名测试文件：

• px0_test.go：忽略规则、模糊搜索排序等基础行为
• search_test.go / fuzzy.go：工作区搜索与模糊匹配
• git_test.go / pr_test.go：Git 集成与 PR 审阅
• highlight_test.go / table_test.go：语法高亮与表格视图

运行完整测试套件：

make test

看到ok px0即表示全部通过。若涉及性能相关改动，建议再跑一次基准，与 BENCHMARKS.md 中的既有数据对比：

make bench # Go 微基准（ns/op、B/op） ./benchmark.sh --memory bench-repos/linux # 内存生命周期追踪

benchmark.sh 会启动真实服务器、用 curl 计时、从/api/metrics采样内存，所有数字都来自实测而非估算——这正是 px0 基准方法论的精髓。

五、源码地图：10 分钟看懂核心模块

px0 服务端刻意保持"扁平单包"风格，所有 Go 文件都在根目录，按职责一眼可辨：

每个模块的深入原理都有对应文档：docs/internals/architecture.md（总体架构）、docs/internals/indexing-and-ignore.md（索引）、docs/internals/editor-virtualization.md（虚拟渲染）等，动手改代码前先读一遍对应文档是高效做法。

六、参与贡献 px0：先读 CONTRIBUTING，再提 Issue

这是 px0 贡献流程中最特别、也最容易被忽视的一点 📌

px0 的开发完全由AI 编码代理驱动——所有实现、重构与变更都由 AI agent 依据核心设计原则编写。因此按照 CONTRIBUTING.md 的说明，项目通常不接受手工编写的自发代码补丁（unsolicited PR）。

那么新手能做什么？最有价值的贡献恰恰是"非代码"的：

1. 🐛 提交高质量 Bug 报告先检索已有 Issue 避免重复，然后提供完整上下文：操作系统、浏览器、工作区规模、复现步骤、期望与实际行为、日志与截图。

2. 💡 提交有论证的功能建议说明动机：解决什么问题？为什么用户需要？如何契合 px0"读取优先、极简足迹"（reads-first、minimal-footprint）的设计哲学？

3. 维护流程维护者会把每个 Issue 对照设计哲学评审，评估可行性后，由 AI agent 完成实现、测试、基准验证与发布。

如果你希望深入理解改动必须遵守的工程规范（文档同步矩阵、提交前验证清单），docs/agents/README.md 中的"Documentation Maintenance Protocol"与"Pre-Commit Checklist"是最好的参考——哪怕不提代码，理解这些规则也能让你写出更精准的 Issue。

七、了解发布流水线：make publish 如何工作

虽然普通贡献者不负责发版，但了解发布机制有助于理解 VERSION 文件（当前版本 0.1.16）与dist/产物的关系。PUBLISHING.md 描述了完整流程：

• make publish <version>：自动更新 VERSION、打包前端、交叉编译所有平台二进制、提交并打标签；
• 推送后由 CI 生成带checksums.txt的发布产物，自更新器（px0 --update）会校验二进制后再替换；
• 发版前必须通过make test+make build双重验证。

结语：三步开始你的 px0 开发者之旅

回顾一下最短路径：

1. 装好Go + Node.js，git clone后执行make build得到本地二进制；
2. 用go run . -dev .开启热加载调试，用make test守护每一次改动；
3. 阅读 CONTRIBUTING.md，用精准的 Bug 报告和功能建议参与贡献。

px0 的极简架构（单包 Go + 原生 ES 模块）意味着新人读源码的门槛极低——这正是从"构建者"走向"贡献者"的最佳起点。🚀