我还没写过关于别人的文章的评论，所以打算尝试这么一种形式：推荐一些文章，并附上我的评论。
这是本系列的第一篇。
最近读到一篇关于依赖项更新的文章，想聊聊我的看法。原文在此阅读。给太长不看的读者总结如下：
David Lord维护着众多GitHub库，其中许多已趋于稳定，鲜需更新。他发现来自Dependabot和pre-commit.ci的自动依赖更新PR（每月每个项目约3个）造成了大量通知噪音和无效劳动，尤其是每月月初。这让他难以识别重要通知，并制造了项目活跃的假象。虽然自动更新对应用程序很有用，但类库并不需要这种持续关注。为此，他关闭了自动更新功能，转而使用
pip-compile、pre-commit和自研工具gha-update（用于GitHub Actions）创建本地更新命令。现在他只在主动开发项目时手动更新依赖，既能确保固定依赖环境可用，又能在需要时灵活升级。他通过tox管理这些更新命令，并用all-repos批量执行，从而完全掌控更新节奏。
我有三点——也可能是四点——想说：
- 这篇文章好在哪？
- 对作者论点的反驳
- 文中一个与主题无关的细节
- 以及我的随想
首先声明，我不同意他的某些观点。
但正确之处也不少。凡事总有可取之处，没有绝对错误的事情，对吧？
先说优点：为保持统一的开发体验，固定依赖版本并定期更新是正确的做法。
如果依赖版本设定为范围（比如大于某版本号），本质上就不可预测，更容易遭受供应链攻击。若对供应链攻击和依赖混淆攻击感兴趣，可读我的旧文：
作者希望按自己的节奏升级依赖，理由有三，但在我看来都站不住脚：
- 他提到每月每个仓库3个PR造成的操作负担（滚动点击等），但这完全可以通过自动合并解决。况且更新频率本就可调，后文详述
- 他拥有20个仓库——这是极端案例。不能因为你无力维护20个仓库，就否定自动化更新对单个仓库的价值，这种逻辑不成立
- 自动化优于人工：零人为失误，零操作负担。综上，他的论点难以服人
第三点想谈个细节：
“对于应用程序，特别是配置了持续部署的场景，定时更新可能合理。你希望尽快部署所有错误修复和安全补丁。”
“对于类库，这些依赖仅在本地的开发环境运行。虽然新功能和修复很诱人，但并不需要持续即时关注。”
我持异议，尤其针对前半段。
即便是配置了持续部署的应用程序，也不该总是立刻升级到最新版本。关于这点我早年写过博客。
绝大多数漏洞和安全问题都集中出现在软件生命周期的前几个月，之后数量会急剧下降。这就是为什么Firefox、Chrome等关键软件都提供企业支持版，其版本往往落后标准版数月甚至数年。月度更新都嫌频繁，我倾向于季度更新。
最后，也是这篇文章的重点——我想分享近年阅读的一个感悟：作者应当对文字可能改变读者观念乃至人生的力量保持敬畏。举例说明：
偏爱手动操作本无妨，这是你的自由。
我自己就常手动处理：无论是单车还是汽车，我都享受换挡的掌控感；经常懒得写正则表达式匹配文本模式，而是在Sublime Text里按住Command+D逐个选中。我有的是时间，等得起"一会儿"。
但是（这个"但是"很重要），我绝不会建议你也这么做。这只是我的个人癖好，懂吗？我断不会为此专门写博客宣扬手工操作。能写≠应该写，尤其是这种仅符合小众偏好的主观选择。我不愿输出本质上"不正确"的内容。
然而（这个"然而"同样重要），作为Flask核心开发者——具有一定行业影响力的人物——下笔时理应对读者和社区多几分责任感。你要明白大多数人并不维护20个仓库，也不会每月处理3个依赖更新PR。更不该把特定场景下的个人工作流包装成普适建议公开发表。经验不足的读者可能会盲目追随：既然Flask大神都这么做，肯定是最佳实践吧？
再举个文学例子。
我喜欢的日本作家村上春树有本《刺杀骑士团长》，主人公是个住山间豪宅的富豪，开捷豹，每天凌晨2点失眠醒来，喝着威士忌配腰果。
他许多作品都有类似描写。当这类细节积累到一定程度，读者难免产生"喝威士忌配腰果很高级"的联想——既然是名家笔下被富豪主角青睐的生活方式，想必很有格调？我也该试试？
我们通过所见所闻塑造世界观，这些输入在某种程度上决定了认知的边界。
借此机会想对所有写作者说：少写些自我陶醉的内容，多承担几分责任。何乐而不为呢？