HackerNews中文版

我正在将更多项目迁移到 uv，因为它确实非常出色——比其他任何工具都快，解决了实际问题（甚至是像 venv + wxPython + macOS 这样的边缘情况），而且用起来非常顺手。但我感觉锁定效应正在累积。每个项目都会添加 uv 专属的配置，CI 依赖于 uv 的行为，团队也习惯了 uv 的工作流程。GitHub Action 用起来很方便，所以我们使用了它。解析器更好用，所以我们依赖它。我们以前看过这样的戏码。优秀的开发者工具变得不可或缺，然后商业现实就会到来。即使是谷歌也放弃了“不作恶”的口号。劣币驱逐良币的模式已经被充分记录：在用户被锁定之前对他们好，然后开始压榨。我不是说 Astral 会这样做，他们似乎真的专注于开发者体验。但这是每个人在最初几年都会说的话！你对此有什么看法？你正在构建抽象层吗？保持备用工作流程的测试吗？还是只是接受如果未来需要，就处理迁移？我一直在采用 uv，因为它在技术上是正确的选择，但我对如果事情在 2-3 年内发生变化而没有任何真正的备用计划感到不安。工具越好，最终的锁定就越深。

查看原文

I'm migrating more projects to uv because it's genuinely excellent - faster than anything else, solves real problems (even edge cases like venv + wxPython + macOS), just works.But I'm feeling the lock-in accumulate. Each project adds uv-specific configs, CI assumes uv behavior, team gets used to uv workflows. The GitHub Action is convenient, so we use it. The resolver is better, so we depend on it.We've watched this movie before. Great developer tool becomes indispensable, then business realities hit. Even Google dropped "don't be evil." The enshittification pattern is well-documented: be good to users until they're locked in, then squeeze. Not saying Astral will , they seem genuinely focused on developer experience.But that's what everyone says in the first few years!What's your approach here? Are you building abstraction layers? Keeping alternative workflows tested? Just accepting that you'll deal with migration if/when needed?I keep adopting uv because it's the right technical choice, but I'm uneasy about having no real fallback plan if things change direction in 2-3 years. The better the tool, the deeper the eventual lock-in.

问 HN：你的紫外线退出策略是什么？