随意修改系统默认的 python 环境可能会出问题的吧......尤其是替换了环境变量和软链接

对的，建议注明风险

几乎所有python开发都有办法在环境中自定义python版本，为什么一定要改系统的呢？

这种情况下用conda跑或者单独给这个软件设置环境变量就好了。

我这里就有一个小飞机软件依赖python2，一个词典软件 (google-translate-for-goldendict) 依赖python3.7+，一个音乐下载软件 (netease-cloud-music-dl) 依赖python3.0-3.9，然后我系统（manjaro）软件源里面的软件全部都是为python 3.11构建的。python开发的软件依赖不同python版本和库的多了去了，怎么可能通过给系统更换python版本解决。

觉得conda笨重的应该是没搞懂conda。实际上conda本体很小，大的那些依赖都可以不安装。

我不反对编译python。我反对的是替换系统的python版本。系统仓库源内的所有python软件都是针对系统python版本构建的，替换系统python版本会导致仓库内的软件无法正常运行。况且，系统python再怎么替换也就是一个，实际上完全无法满足不同软件的python需要。

能够满足自己的需要就叫搞懂。anaconda，miniconda，memba，甚至venv+pip（虽然其中有的名字不叫conda，但是他都写明了是conda替代了），只要能够满足自己的需要就好。

另外我都说了我不反对编译python，我不反对编译python，我不反对编译python。

我反对的是替换系统python。替换系统python风险太高，而且很多人并不清楚这个风险，也不知道如果出问题了要怎么解决。

如果这个需求只能通过替换系统python解决，而且清楚替换python的所有风险和对应的解决方案，那么我一句话都不会说。但事实是，这篇帖子的需求和你的需求都不是必须通过替换系统python解决的，而且帖子闭口不提替换python的风险。这种情况下，很难说这个行为是满足了需要。

对于这种技术文章我其实也不太认同……我始终认为应该进行风险提示。

另外他这个帖子，原理没怎么说，命令和图片倒是贴得非常详细，有一点基础的人靠复制粘贴都能完成。这种风险操作，又只贴命令不解释的，自己做笔记就算了，做成教程和分享真的很容易误导小白。

vscode+pipenv呀，pycharm又是跟小甲鱼学的吧。

都2023年了，还有依赖问题的包不多了，建议与其多花时间研究如何改系统Python还不如好好研究下替代的包，尽量不那么挑Python版本。

这种小白万一是别的搞错了，然后以为是自己py版本问题，跟着一通操作，然后系统崩了，妙呀。

小白走弯路对于教程的提供者并没有什么好处。前人踩坑的意义不正是为了为后来人排雷吗？如果每个人都要走一模一样的弯路，浪费一模一样的时间，那人类如何进步？

他不说，所以我说；如果小白往下拉看到我的回复，也许就能知道这样做的风险，也许就能避免系统崩溃所带来的时间与财产损失。