北京
“那只是能编译且测试通过的版本。”这是Pilum作者对2025年12月开源时的评价。不到100天，这个能从一份 pilum.yaml 同时部署到 Cloud Run、Lambda、Azure、Cloudflare Pages、npm、Homebrew 和 Docker Hub 的多云端 CLI，经40多次 PR 打磨后，已经承包了 SID Technologies 旗下所有网站、npm 包乃至自身的发布。但从“能跑”到“能跑生产”，中间炸过的雷远比想象得多。
我们把时间轴拉直：2025年12月2日首次提交，搭好配方系统；12月4日 Self-dogfooding，用自己发布 Homebrew。年底前服务图、--only-changed 和文件嵌入到位。1月是“哦，这玩意儿原来不 work”的安静修 bug 期。真正的风暴在2月——6到7号，48小时内塞进8项大功能：Wave 部署、npm 配方、Cloudflare Pages、Azure容器应用、Cloud Run Jobs、环境变量、JSON 输出和 history 命令。然后？从8号到12号，紧急修复这些功能引发的一切：YAML 解析崩坏、包管理故障、构建失败、错误静默吞噬、GCP 密钥问题、Cloudflare 执行异常。2月底补安全加固和 npm 发布漏洞。到了3月，作者以为翻篇，结果又撞上内存分配、波排序错乱，最终把整个调度器拆了重写。
这里面最惨烈的当属 Wave 部署。当初作为 #31 的头条功能，服务声明依赖后，Pilum 会构建依赖图、拓扑排序成多个波次、并行执行。单元测试完美。然后轮到发布 npm 包——@sid-technologies/base-ui 依赖 @repo/configs，二者在同一个 monorepo，波序也正确把 configs 排在前面。但 worker 分配却没有按波边界等待：第2波的 Goroutine 可能在第1波还没完全退场时就启动了。npm 仓库因此随机性拒绝 base-ui，有时成功，纯粹是竞态条件撞大运。
最终修复 (#61) 做了两件事：一是基于内存的 worker 分配，不让机器超载；二是真正的波屏障——第 N 波所有 worker 成功完成后，N+1 波才被允许启动。为此整个调度器在 #60 中被重写：原 runner.go（772 行）被 execution.go、pipeline.go、steps.go 等新文件取代，实现了严格的消息传递、归拢和成功上报。现在，Pilum 用自己的时间线证明了：功能可以快速狂飙，但生产级的稳定，只能靠一层层真实报错堆出来。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
