当每一次写入都有了新价格

使用者痛点：硬盘空间骤减、SSD 写入寿命逼近上限、硬件更换成本飙升，导致开发者在日常调试和部署时频繁遭遇「磁盘已满」或「设备寿命告急」的警告。

最近，OpenAI 的 Codex 被发现存在一个日志写入问题：程序会持续向本地数据库写入大量日志。导致文件不断膨胀，并产生远超正常水平的磁盘写入。差不多 Bug 过去并不少见。怎么说呢，放在几年前，人们大概只是删除文件、重启应用。接下来等待下一个版本修复。

但这一次大家的反应明显不同。比起“还剩多少硬盘空间”，更多人开始关心 SSD 已经累计写入了多少数据。会不会影响闪存寿命，还有未来更换设备时需要为一样容量的内存和存储多付多少钱。

Codex 的 Bug 未必比过去那些失控的日志程序更加严重。真正发生变化的是：每一次无意义的写入，似乎都重新有了价格。

因为 AI 算力需求迅速增长，存储器厂商越来越倾向于优先保障 HBM、服务器内存和公司级 SSD 等利润更高、需求更旺盛的产品。其实，消费级内存和 SSD 能够分配到的产能所以受到挤压。价格也不断走高，

内存和闪存本来就是典型的周期性领域，价格上涨和下跌并不罕见。话说回来，但这一轮变化令人不安的地方，在于它似乎不再只是一次简单的库存周期。而是伴因为产业资源向 AI 基础设施长期倾斜。

即使价格最终仍会回落，使用者恐怕也很难迅速回到过去那种“大容量近乎免费”的心理预期。

当存储不再显得取之不尽时开发者或许也应该转变对资源时的态度。

从硬件限制到代码习惯的转变

在我最开始接触电脑时Apple II 常见的内存配置只有 KB。为了使用 卡额外提供的 KB 空间。开发者需要仔细安排地址、代码和数据，想方设法把每一个字节都利用起来。话说回来，

今天一个数十 GB 的游戏。必然拥有 FC 时代无法想象的画面、声音、世界规模和交互复杂度。只是巨大的容量并不能保证它带来的乐趣一定超过一个只有几十 KB 的游戏。 其实，

这并不是说现代软件不应该变大。真正值得思考的是在过去很多年中，开发者已经习惯了存储容量会自然增长、网络会不断变快。日志、缓存和临时数据只要暂时还放得下就很少有人追问它们为什么存在又将在什么时候被删除。

痛点回顾：

• 磁盘占满导致 CI/CD 建立失败；
• SSD 写入次数逼近保质期，引发硬件故障报警；
• 成本预算被意外膨胀，需要重新评估硬件采购策略。

昂贵的 SSD 不会自动创造优秀的软件，内存短缺也不会让开发者突然变得更加聪明。但当硬件不再被默认会无限增长时那些曾经被忽视的工程问题便会重新浮出水面。

恢复工程习惯的关键性

我并不怀念那个需要在几十 KB 中反复腾挪的时代。真正值得重新拾起的，并不是资源匮乏。而是那种曾经十分自然、后来却逐渐消失的工程习惯：

近期推荐

这是一篇来自 Apple Developer Forums 的问答。怎么说呢，提问者发现，一个会串行执行多个 REST 请求的 Swift Task。在设备锁定后有时能够正常完成，有时会暂停，甚至出现超时。DTS 工程师 Quinn “The Eskimo!怎么说呢，” 解释道，Swift Concurrency 完全运行在应用进程中；一旦 iOS 挂起进程，执行 Task 的工作线程也会停止。Task 本身并不会获得额外的后台运行能力。说起来，

这种机制在网络请求中尤其容易造成困惑。应用被挂起时正在进行的 URLSession 请求可能因连接失效而失败；进程恢复后开发者看到的可能是请求超时或网络错误，而不是 Task 从暂停处继续并顺利完成。Quinn 给出了四种处理方向：设法延缓进程挂起、在应用即将被挂起时停止请求、允许请求失败并做好重试与错误恢复，或者使用 URLSession 的后台会话。