Qv2ray 检测到 DDE 环境，提示弹窗：Deepin 设置代理错误

简述：　使用 Deepin + QV2ray 的用户，有遇到如下提示弹窗；这里说一下事情的始末发展。

[TOC]

本文初发于 “偕臧的小站“，同步转载于此。

碎碎念

印象中让人深刻的一句话～

本篇是来兑现之前的承诺，虽然 咕～咕～咕～ 了很久，但是一天没回复，睡觉始终心有不安。感觉心里有什么在牵挂这一样，，，

本篇仅是个人观点，说明此缺陷为何一直延期很久才解决。无意代表 Deepin 官方；

也有考虑过是否将本篇其发布出来，犹豫甚久；若是同事或者领导看到了，若是不高兴了，万一被咔嚓，，，，，，

若有，会略有失望；一份工作，也仅是生活的一抹重笔；

若无，说明我没看错，（至少我的直属领导和我认识大领导，和周围比较亲近的人，他们是很友好且心善的、非求生欲，实话实说））（也是我留下来在 Deepin 的一个重要原因）。

此文落笔时，没想那么多，也没考虑那么多；也不准备想那么多，也不想考虑太多～～

同样，本篇既不是洗白、或者黑某个事物或者个人，单单称述一件事情的发展过程罢了。帮助各知晓。

文中的语气，仅标表明说当时那一刻瞬间感觉，过后就忘了，没有忧愁的我，，，哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈，，，， （网络是有记忆的，发表容易日后埋雷。已记不清有多久没在公众网络上，发表个人观点了。但今天想了一下，将保存好的草稿略加修改，将其发布于 2020 年的年末一天。）

起因

Deepin可能自作聪明，为你设置了错误的 HTTPS_PROXY 和 FTP_PROXY 环境变量。

原来正确的 http:// 可能被错误地替换为 https:// 和 ftp://，导致这个问题。

Qv2ray 很遗憾无法帮你改回来。若因此遇到问题，请勿指责吾等。

对于 Deepin / UOS 、Arch + DDE 、 manjaro + DDE 等的用户，且同时是 Qvray 的用户，都有遇到过此如下此 “提示” 弹窗。有让很多使用者和开发者比较困惑，这里回复一下为啥很久，此 Bug 才被修复，顺带向上延伸一下。

时间线

为了方便描述，这里按照记忆中的时间线描述下，时间大致差不多～；

此前是 Deepin v15 版本，暂略

资本下场 2019-07 左右，着手开发 V20 版本，大招人，全速开发迭代新功能、新特性

到约 2020-01 V20 版本基本定型，开始重点提升质量，打磨细节，修改 BUG

2020-02 下旬 疫情封城和过年双临，开始远程办公，研发进度略缓

2020-03 下旬 ，通知再次组织开源仓库，因为中间 9 个月没有怎么更新代码，可能都忙晕（我也是后来才知道，原来 Deepin 版本居然是实时开源的，顿时震惊和狂喜）；自荐和 blumia 大佬一起负责对外开源事宜。手工核对开源仓库的初始表，然后让老大和老大的老大双确认下。再手工每个仓库设置同步，于是就这样 Deepin 的仓库，再次回复大更新，后面就一直是保持了实时更新的。

2020-04-15 在 jingle 催更新下，出了 deepin v20 Beta 版本，若再跳票一直不出，社区估计会被口水淹没。

2020-05-10，提了此 issues： #15，但社区之前一直都是大佬们兼职负责，没人专门负责，空了一段时间；当我第一次遇到此弹窗的时候（en，我也是这两者的用户），没在意，顺手关闭提示，以为只是一个小的 bug，以为按照现有流程，过几天就会被修复，且没有感觉有影响到我使用（开启/关闭全局代理解决的，虽然缺失优雅）。

2020-06-30 快一个月快过去，此还未被修复，也仍未被后端所重视，然后 DuckSoft 做了一个提交 cbd8ac9a8a ，助其合并，我和他都以为就 ok 了。但是，，就有了文章后半部分

2020-08-27 ，又过很久，还有人反馈问题，且每次打开后来反复提示，emmmm。这都是赤条条的明示了！！！在黑 Deepin 嘛！！！不过也确实，我都感觉不好意思了，居然能够被拖近 4 个月之久。。。醉了醉了醉了

抽空去看看这是啥原因？跑去翻了下当时的记录，发现此贡献提交到了 develop 分支（当时都没注意），而由于策略，这是是搁置无用的分支，只有提交到默认分支 uos / master 分支才会有效。氪！！！

知道问题后，再麻烦人家重新提交、岂不是尴尬，，，，，不好意思了，老脸一红。欲自己修复，做好事不留名，可后端不懂，找到后端大佬，让研发大佬协助一下，研发做了提交到 master 分支 f3021d13 ， tag 为 5.5.0.1 觉着这下应该稳妥了。后面慢慢跟新一番即可，终于可以安逸一会了，后面应该不会再黑 Deepin 了吧（单指去掉改提示框，不过Deepin 这件事确实做的不够好，被人家疯狂暗示，也是无可厚非～，似乎没有什么不妥）。

然后遇到准备一周后 09-11发社区版本的更新，但是当时的很多包的tag 号都定了，但是 go-lib 项目 tag 偏低，按照当前的跟新速度，用户想得到这个修复，估计得 2021 年初去了。。。。（很是惶恐，害怕，这 TMD 后面必须跳跃版本解决，或者改变现有策略）

然后想了下，能不能直接将 go-lib 项目色升级到最新的 tag，那样用户就可以早点用上了；商讨的结果，就是不能升级。

原因如下：

① go-lib 项目是一个很重要的基本包，然后过多重要的核心包也都依赖它；

②此项目的独特殊和机制，不能像普通软件一样，只是更新一下动态库升级得到此修复。

③发布时间已经预定了，来不及更改了；且即使升级，也需要对应的软件包全部升级才行，测试小姐姐前面的测试也都白费了，且需要重新测试一轮，可能当场就狗头不保。文案内容也都要全部重新写，运营在论坛宣传也都跳票了。想一下，都觉得寒毛爆炸。被磨刀霍霍～～

这是第一次感觉到心累的感觉、也是第一次感觉到牵一发而动全身。什么叫做被迫，只好让社区用户再次等待，，嗷～嗷～嗷～，虽然理解，但我还是有张图要说

2020-09-17 时候，决定更换策略，社区版本不应该跑在专业版后面太多；也完全可以跑到最前面，让社区用户体验新特性新功能，和反馈新的缺陷。然后直接按照当时最新的专业版所有 tag，全部照着来一遍，此时心里美滋滋的，第一反应就是将 go-lib 项目打 tag 到 5.6.0.2，真的是可开心了。想着他们终于可以用上此修复了了。且这此打包我主要负责，可以一下将很多包直接推送到到最好的兼容版本。

预料之中在 2020-10-23，在内测的 1030 版本中，已经验证了此 bug 被解决，且该弹窗提示也在新的 Qv2ray 里面被移除了 #1050 ，互相都很开心。后面收电报等公告 thanks了，甚是开心。

然意料之外发生了，在 2020-11-13 周五时候，因为 “应用代理开启后无法打开应用商店” ** （BUG 号：53612），然后研发小组长、研发、测试、产品经理、项目经理建群讨论，且急于下班之前集成版本，优先级也比较高，** 时间也比较短，给出的 临时解决方案是：由于设计缺陷，只能先修改回去，后面代理这一块在下一阶段需要重新设计。改回去的提交 a1b16c48 呜呼载～，前面的修改都是白费了，心疼又心痛！！！ ~~都是想要做事，都想将其做好，若是深究的话，感觉没有任何一个人有做错什么，有的只是事情的轻重缓急之分。~~