1. 当你在Windows上创建环境时那个恼人的“~”错误从何而来相信很多朋友在Windows上用Conda创建Python环境时都遇到过这个让人一头雾水的报错CondaValueError: Malformed version string ~: invalid character(s)。你可能只是想简单地跑一句conda create -n myenv python3.7结果环境没创建起来反而收获了一个关于版本字符串格式错误的提示。这个错误信息指向一个神秘的波浪号“~”但你的命令里明明没有这个字符啊这感觉就像车在半路抛锚仪表盘却显示一个你从未按过的按钮坏了非常令人困惑。我第一次遇到这个坑时也花了大量时间排查。表面上看错误是“版本字符串格式错误”指向了无效字符“~”。但问题的根源往往不在你输入的命令里而在于Conda在背后为你“默默”做的事情——依赖解析。当你执行conda create时Conda会去它的“仓库”我们称之为通道或channel里查找匹配你要求的软件包。如果这个仓库的地址不对或者返回的数据格式Conda无法理解它就可能把一些元数据信息错误地当成版本号来解析从而产生这个诡异的“~”字符错误。这个“~”字符很可能来自某个镜像源返回的、不符合Conda版本规范的数据包描述信息。所以别急着去修改Conda的底层代码比如那个网上流传的修改site-packages/conda/models/version.py文件的方法。那属于“头疼医脚”而且风险很高一旦Conda升级修改就会被覆盖。我们真正需要做的是理顺Conda获取软件包的渠道也就是配置好镜像源。一个稳定、格式规范的镜像源是Conda能够正确解析依赖和版本信息的前提。接下来我们就一步步拆解这个问题从理解Conda版本规范开始直到给出一个一劳永逸的配置方案。2. 拆解Conda版本字符串规则远比你想的严格要根治问题得先理解Conda是怎么看待“版本”这个东西的。Conda的版本字符串Version String解析有一套非常严格和具体的规则它可不是简单地把数字和点拼起来就行。这套规则基于PEP 440Python增强提案但又有自己的扩展。一个合法的版本号通常看起来像1.2.3、2.0.0rc1或者2019.10。关键点在于版本字符串中只允许出现特定的字符集。主要包括数字0-9。字母a-z, A-Z但在比较时通常不区分大小写。分隔符点.、连字符-、下划线_。预发布标识符在数字版本号之后可以跟aalpha、bbeta、rcrelease candidate等。开发版本标识符.devN。本地版本标识符local。那么波浪号“~”在哪里呢在标准的Conda版本规范里“~”并不是一个合法的版本字符串字符这就是为什么当Conda的解析器遇到它时会毫不犹豫地抛出一个Malformed version string错误。这个字符的出现几乎可以断定是外部输入污染了版本数据。想象一下这个场景Conda向一个软件源请求“给我python 3.7的所有可用版本列表”。正常的源应该返回一个干净的列表比如[“3.7.0”, “3.7.1”, “3.7.2”, …]。但如果这个源配置有问题或者网络响应被劫持、格式错误它可能返回了一些夹杂着特殊字符或错误格式的字符串。比如可能返回了某个包的完整依赖字符串里面包含了用于表示“大约”版本的~操作符这是pip的语法不是Conda的或者是一些未处理的元数据标记。当Conda试图把这些字符串当作版本号来解析时“~”这个非法字符就暴露了错误由此产生。2.1 为什么常见的“急救”方法会失效在网上搜索这个错误你会找到很多“解决方案”。我们结合原始文章里提到的失败案例来分析一下为什么它们常常不起作用删除或移除conda-forge通道很多人发现错误信息里提到了conda-forge就尝试把它从配置里移除。这有时能“碰巧”解决问题因为可能恰好是conda-forge这个源的某个镜像出了问题。但如果你的.condarc文件里还有其他配置不当的镜像源或者defaults源本身访问不畅问题依旧会存在。这属于“治标不治本”而且conda-forge是一个非常重要的社区源很多包都在那里移除它会限制你的选择。更新Conda本身执行conda update conda或conda update --all。这个方法的逻辑是“升级到最新版修复可能存在的Bug”。对于因Conda自身旧版本解析器Bug导致的问题这确实有效。但对于我们遇到的、因镜像源数据格式问题引发的错误更新Conda并不能改变远端服务器返回的数据内容。数据格式不对再新的解析器也报错。修改Conda底层代码这是最不推荐的做法。去修改site-packages/conda/models/version.py这类文件试图让解析器“容忍”~字符。这破坏了Conda版本解析的一致性可能导致后续依赖解决出现更隐蔽的错误。而且每次conda升级你的修改都会被覆盖需要重新修改非常麻烦。这些方法之所以失败是因为它们没有触及问题的核心Conda正在从一个返回了不规范数据的服务器获取信息。我们的主攻方向应该是确保Conda连接到一个稳定、可靠、数据格式标准的软件源。3. 根治之道深度配置你的.condarc文件要让Conda稳定工作关键就在于正确配置.condarc文件。这个文件位于你的用户目录下Windows在C:\Users\你的用户名Linux/macOS在~它决定了Conda的所有核心行为尤其是从哪里下载包。原始文章里给出的最终解决方案是一个完整的.condarc配置模板。它之所以有效是因为它做对了几件关键事指定了明确的、可访问的镜像源地址并且理顺了通道的优先级。我们来逐项解读这个配置并理解每部分的作用。首先一个最精简但能解决问题的配置可能长这样channels: - defaults show_channel_urls: true ssl_verify: falsechannels: - defaults这告诉Conda只从官方默认通道defaults查找包。defaults通道实际上包含了main和free等子通道。这避免了从其他可能出问题的社区通道如conda-forge获取数据。show_channel_urls: true这个选项非常有用。它会让conda install或conda create在输出中显示每个包具体是从哪个URL下载的。当出现问题时你可以清晰地看到Conda在尝试连接哪个服务器便于排查。ssl_verify: false这是一个为了方便而采取的折中方案请注意安全风险。它跳过了对SSL证书的验证。在某些网络环境下如公司内网、校园网访问镜像源可能会遇到证书验证错误导致连接失败。关闭验证可以快速绕过这个问题但理论上降低了连接的安全性。在能够正常访问的情况下建议将其设置为true。然而仅仅这样配置你连接的可能还是官方的、位于国外的repo.anaconda.com速度可能很慢甚至超时。因此我们需要将defaults通道的地址映射到一个国内的、速度快的镜像站。这就是完整配置方案的精髓。3.1 详解完整镜像源配置方案下面这个配置是将整个Anaconda的生态仓库全部指向清华大学开源软件镜像站。它比单纯设置defaults更彻底也更能避免因通道混用导致的依赖冲突。ssl_verify: false channels: - defaults show_channel_urls: true channel_alias: http://mirrors.tuna.tsinghua.edu.cn/anaconda default_channels: - http://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main - http://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/free - http://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r - http://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/pro - http://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2 custom_channels: conda-forge: http://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud msys2: http://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud bioconda: http://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud menpo: http://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud pytorch: http://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud simpleitk: http://mirrors.tuna.tsinghua.edu.cn/anaconda/cloud envs_dirs: - /anaconda/envs pkgs_dirs: - /anaconda/envs我们来分解一下关键部分channel_alias这是通道别名。当你使用一个没有在custom_channels中明确指定的通道时Conda会尝试在这个别名指向的地址下寻找。例如如果你加了一个通道- my-channelConda会去http://mirrors.tuna.tsinghua.edu.cn/anaconda/my-channel查找。default_channels这里完全覆盖了defaults通道的实际组成。它明确列出了defaults通道对应的所有子通道在清华镜像上的具体路径。这确保了当你使用- defaults时流量百分之百走向国内镜像而不是在某个环节又绕回国外源。custom_channels这是配置的亮点。它为你常用的社区通道如conda-forge,pytorch创建了别名映射。这意味着当你把conda-forge加入channels列表时Conda会自动去清华镜像的对应位置查找而不是官方的conda-forge仓库。这既享受了社区包的丰富性又保证了下载速度和数据格式的规范性。如何应用这个配置找到你的.condarc文件。如果不存在可以在命令行执行conda config --set show_channel_urls yesConda会自动生成一个。用文本编辑器如Notepad, VS Code不要用Windows自带的记事本可能编码有问题打开这个文件。将文件现有内容全部删除然后把上面的完整配置粘贴进去。注意对于Windows用户envs_dirs和pkgs_dirs的路径可能需要修改例如改为C:\Users\YourName\anaconda3\envs这样的实际路径。如果不确定可以暂时删除这两行Conda会使用默认位置。保存文件关闭编辑器。完成之后打开一个新的终端重要让配置生效再次尝试你的conda create -n DAMO-YOLO python3.7 -y命令。这时Conda的所有请求都会被导向清华大学镜像站。由于该镜像站数据完整、格式规范之前那个因数据污染导致的“~”字符解析错误自然也就消失了。4. 进阶排查与验证当配置后问题依旧在绝大多数情况下通过上述深度配置.condarc文件问题都能得到解决。但如果你配置后仍然遇到问题我们可以进行更进一步的排查这能帮助你更深入地理解Conda的工作流程。首先利用我们之前设置的show_channel_urls: true。在执行命令时仔细观察输出。在“Solving environment”阶段前后Conda会打印出它正在查询的通道URL。检查这些URL是否确实是你配置的清华镜像地址包含mirrors.tuna.tsinghua.edu.cn。如果出现了其他奇怪的域名或IP说明你的配置可能未被完全应用或者存在其他地方的配置覆盖了用户目录下的.condarc。其次可以尝试使用conda clean -i命令。这个命令会清除Conda的索引缓存。Conda会缓存从通道获取的包元数据以加速后续操作。有时旧的、损坏的缓存文件可能导致解析错误。清除缓存后Conda会强制从你新配置的镜像源重新拉取一份全新的、干净的索引数据。另一个有用的命令是conda info。它会输出大量关于当前Conda环境的信息。重点关注这两部分channel URLs这里列出了当前生效的、所有通道的完整URL列表。确认它们是否符合你的预期。config file这里显示了Conda正在使用的配置文件路径及优先级。Conda会按顺序读取多个位置的配置文件如系统级、用户级、环境级后者覆盖前者。确保你的用户级.condarc文件路径出现在这里。如果问题非常顽固可以考虑创建一个“最小化测试环境”。使用conda config --show-sources查看所有配置源然后暂时将.condarc移走用一个只包含最基本镜像配置如仅channels: - defaults和ssl_verify: false的新文件来测试。这可以排除复杂配置中某个字段书写错误导致的意外影响。最后关于镜像源的选择清华大学镜像站Tuna是一个优秀且稳定的选择。如果你在使用的过程中发现某个包版本不全或同步延迟也可以考虑切换到其他国内镜像例如北京外国语大学开源软件镜像站、阿里巴巴开源镜像站等它们通常也提供Anaconda镜像。方法类似只需将配置中的mirrors.tuna.tsinghua.edu.cn替换为对应镜像站的域名即可。配置的核心思想是不变的为Conda提供一个单一、稳定、格式规范的软件源入口避免它在多个格式不一的源之间混乱查询这才是从根本上杜绝“Malformed version string”这类诡异错误的钥匙。