凌晨两点，源代GitHub 上一条 issue 弹出提示：某个开源项目的码网贡献者把一份 200MB 的二进制补丁包直接拖进了 web 上传框。五分钟后，站网服务器内存飙到 90%，络文前端进度条卡在 99% 不动了。提交系这不是源代个例——几乎每个维护过代码仓库的人都经历过这种“上传即崩溃”的尴尬。

源代码网站的码网提交系统，本质上是站网个文件搬运工，但它要搬的络文不是普通文件。是提交系代码。是源代带依赖关系、目录结构、码网版本信息、站网甚至带注释的络文代码。普通网盘上传，提交系传完就完事。代码提交不一样，后端要在几秒内完成文件指纹计算、病毒扫描、格式校验、依赖解析，然后决定是接受还是打回。这套流程的复杂度，跟把一头大象塞进冰箱完全不是一个量级。

我见过最离谱的一次，是某团队往 GitLab 传了个含 3 万个文件的 node_modules 文件夹。前端直接假死，后端队列堵了半小时，最后管理员手动清库才恢复。问题出在哪？上传系统用了同步校验——文件传完才启动检查，3 万个文件逐个算 hash，每个都要几毫秒，加起来就是几分钟的等待。而用户那边，浏览器早就超时断连了。

真正好用的提交系统，得把“上传”和“处理”拆开。文件到达后立刻返回“已接收”状态，后台异步跑校验。用户看到进度条走完就能关页面，几分钟后收到邮件通知结果。这个改动看着简单，但很多团队就是想不到——他们太执着于“提交成功”这个瞬间反馈，忘了用户真正关心的是“代码有没有被正确收下”。

还有个反直觉的设计细节：文件大小限制。不少系统粗暴地设个 50MB 上限，理由是“防止恶意上传”。可现实是，现代前端项目随便打个包就超 100MB，游戏引擎的素材库更是动辄几个 GB。限制太死，等于逼用户走 Git LFS 或者外部网盘链接——这反而破坏了代码评审的完整性。更好的做法是分层设限：文本文件走常规校验，二进制大文件走特殊通道，只做病毒扫描不做内容解析。既保安全，又不卡正常流程。

我调过的一个开源系统，上传接口最初用的是 multipart/form-data 标准格式。测下来发现，传 500MB 文件时内存占用是文件大小的两倍——因为框架把整个请求体都读进内存了。改成 streaming 模式后，内存占用降了 90%，上传速度还快了 15%。就这么个低级优化，很多项目居然一直没做。代码提交不是传照片，文件越大越考验工程细节。

说到底，提交系统的核心价值不在“传”，而在“收得明白”。用户传完代码，系统得告诉他：文件完整、结构合法、没有敏感信息、依赖能解析。这些反馈比进度条重要得多。可惜大多数系统只做到“传完就完事”，剩下的让用户自己猜。这就像快递员把包裹扔门口就走，不告诉你里面东西摔没摔坏——签收延迟、返工成本，全转嫁给了用户。

下次再有人吐槽“上传好慢”，别急着加带宽。先查查你的提交系统是不是还在用同步校验、有没有把大文件请求读进内存、文件大小限制是不是一刀切。代码提交这活儿，糙不得。