问HN：你的用户验证退出策略是什么？
我正在将更多项目迁移到 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.<p>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.<p>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.<p>But that's what everyone says in the first few years!<p>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?<p>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.