发帖人：Deepin 25 用户（截至 2026-10-09）
系统：Deepin 25 / DDE
涉及应用：应用商店版 WorkBuddy、应用商店版百度网盘

---

一、两次踩坑，同一件事

案例 A — WorkBuddy：商店里装的版本，每次启动都弹提示：

发现新版本 V5.5.6.38337834，请前往官网下载并安装。

照做 → 去官网下 deb 装上 → 启动器里出现两个 WorkBuddy，磁盘上两份完整安装目录。

案例 B — 百度网盘（这个更隐蔽）：早年商店里的版本旧，商店又迟迟不更新，我就自己去官网下了 deb 装上。
后来商店终于出新版并提示升级，点了升级——商店只升级了它自己那一份，我手动装的那份原封不动留在硬盘上。
两份一直并存，用了很久毫无察觉。

这两个案例的账，都是我后来做磁盘占用体检时才翻出来的 —— 光靠日常使用，大概永远发现不了。

---

二、案例 A：为什么"跳官网"会装出第二份

1. 两个版本来自两条互不相干的安装通道

通道	包名	落地目录	谁管
应用商店	com.tencent.workbuddy	/opt/apps/com.tencent.workbuddy/	dpkg + 商店
官网 deb	workbuddy	/opt/WorkBuddy/	apt

包名不同、落地目录不同、/usr/bin 入口不同 —— 在 apt 眼里这就是两个毫不相干的软件，
既不互相覆盖，也不互相感知，启动器自然冒出两个同名图标。

2. 提示语是应用自己按"更新渠道"拼出来的

拆开商店版应用的资源文件可以看到，它启动时强制检查更新（updates.startupForceAutoUpdate: true），
并且按官网 deb 渠道去问、不判断自己是不是商店装的。把接口直接拉出来问，服务端行为完全对得上：

# 用低版本身份问（复现我当年看到的提示）
GET .../v2/update?platform=workbuddy-linux-x64-deb&version=5.5.0
→ HTTP 200  {"version":"5.5.6.38337834", "url":".../WorkBuddy-linux-x64-deb-5.5.6.38337834-....deb"}

# 用当前版本问
GET .../v2/update?platform=workbuddy-linux-x64-deb&version=5.6.2
→ HTTP 204  （空，即"已是最新"）

返回体里有个 destination 字段决定弹哪句话：是 uos-store 就说"请到应用商店更新"，
是 kylin-store 就说"麒麟软件商店"，其他/缺省就 fallback 成"请前往官网下载并安装"。
我看到的正是这个兜底文案。

3. 最讽刺的一点

• 应用弹窗说：请前往官网下载并安装
• 官网页面上写：请到系统应用商店下载

两边互相踢皮球。用户夹在中间，照着弹窗做就装出双份。

4. 顺带说清：/opt/apps/<应用ID>/files 这一层属主是 nobody:nogroup、权限 755（商店的安全加固），
应用自身无法原地自更新，装 deb 又必须 root —— 所以问题不在应用"偷偷升级"，而在
它不识别自己的安装来源，拿着商店版去比官网渠道的版本号。

---

三、案例 B：百度网盘 —— 无声无息的双份

这个案例的成因和 A 不同，而且更阴。

我当时的情况：商店版落后 → 自己去官网下 deb 装上 → 过段时间商店出新版提示升级 → 点升级。
结果商店只动了它自己那一个包，我手动装的那个包纹丝不动。

体检时抓到的证据：

	官网 deb 版	商店版
包名	baidunetdisk 8.6.0	com.baidu.baidunetdisk 8.6.0
落地目录	/opt/baidunetdisk	/opt/apps/com.baidu.baidunetdisk
文件数 / 体积	各646 MB、143 个文件	同
inode 号	2641088	2653950
二进制时间	2026-07-10	2026-07-13

• inode 不同 ⇒ 是两份真实独立的文件，不是硬链接（这点必须验，否则可能白折腾）。
• 两份版本号都是 8.6.0，但二进制 md5 不同 → 同版本号、不同构建，说明商店确实升过级，官方那份没跟上。
• /usr/share/applications/ 下两条 desktop 分别指向两处 → 启动器里两个「百度网盘」。

为什么我用着完全没感觉：

• 官方那份从未被运行过 —— 目录内所有文件的 mtime 都停在包自带的构建时间（2026-07-10），没有任何运行痕迹；
• 启动器里商店版排在第 1 页，官方版在第 2 页，我每次点的都是第 1 页那个；
• 两份功能一样，点哪个都能正常工作 —— 所以既不会报错，也不会让人起疑，只会默默吃掉一份硬盘。

一条 646 MB 的"影子程序"，就这样在我机器上躺了几个月。这种双份不靠磁盘体检，根本不可能发现。

---

四、两条路径，一个根因

	案例 A · WorkBuddy	案例 B · 百度网盘
双份怎么来的	应用弹窗引导我去官网装	我因商店落后，自己去官网装
之后会怎样	每次启动反复弹提示	商店正常升级，零提示
用户感知	强（被误导去装）	零（点哪个都能用）
共同点	同一软件在商店 / 官网用了不同包名	同

根因只有一条：同一款软件在两条分发渠道使用了不同的包名。
只要包名统一（都用 com.xxx.yyy 或都用短名），apt 就会视为同一个包覆盖安装，上表两种情况都不会发生。

给官方的三条建议

1（最重要）商店应能识别"同一软件存在其它安装来源"。
技术上不难：按 desktop 条目的 Name= 显示名去重，或按 Exec= 指向的安装前缀（/opt/apps/ vs /opt/）比对，
就能列出可疑的重复项。建议在升级前后提示用户"检测到还有另一个安装来源，是否一并清理"，
或者在商店里提供一个"清理重复安装"的入口。这一条能一次覆盖 A、B 两种路径。

2. 应用内更新检查要识别"我是商店装的"。
商店版应用里已经存在商店标记文件（例如 .workbuddy-store-managed-update，内容 uos-app-store），说明这条路是通的。
建议：安装来源为商店时，绝不要把提示 fallback 成"请前往官网下载并安装" —— 这句话是双版本的直接诱因。

3. 统一包名；退一步，至少给冲突警告。
若确实要用不同包名，请在官网下载页与安装环节明确警告会与商店版并存。

附带提一个数据安全问题：百度网盘商店包的 postrm 里有
for user_home in /home/*; do rm -rf "${user_home}/.config/baidunetdisk"; done
—— 直接卸载会连用户的登录态配置一起删。我清理时不得不先把配置改名暂存。建议厂商自查 postrm 是否该这么写。

---

五、给其他用户的避坑提示

1. 看到"请前往官网下载"先别动 —— 先去应用商店看有没有新版，多数只是慢几天。
2. 不要在商店版之上再装官网 deb —— 这是双版本唯一的来源。真要换官方版，先 sudo apt purge <商店包名> 再装。
3. 曾经手动装过官网 deb 的，建议查一次（商店升级不会帮你清掉那份）：

# 一键找重名应用（双版本的典型症状：同一显示名出现两次）
grep -h '^Name=' /usr/share/applications/*.desktop ~/.local/share/applications/*.desktop 2>/dev/null | sort | uniq -d

# 查到可疑项后，用这两条确认是不是真两份
dpkg -l | grep -i <关键词>                     # 看有几条包记录
stat -c '%i %n' /opt/<名字>/ <商店目录>/…       # inode 不同 ⇒ 真两份，不是硬链接

4. 自查是否被"隐性升级"过（三条对得上就没事）：

dpkg -s <包名> | grep ^Version            # 包管理器记录的版本
grep '"version"' /opt/apps/<应用ID>/info   # 应用自带元数据
stat -c '%y' /opt/apps/<应用ID>/files      # 安装目录最后改动时间

---

六、附：另一类同源现象（不算商店的锅，但表现一样）

我手边还有一款下载工具：商店装的 motrix-next 升级后改名叫 Rayburst，
而我之前自己装过一个 Motrix 2.0 的 AppImage。升级后桌面图标指向被改成了 AppImage，
启动器里又出现同名/近名条目互相遮蔽。
建议商店在应用更名时同步清理旧条目并通知用户，否则用户很难判断自己点开的到底是哪一个。

---

发帖目的是提一条具体的改进建议，不是抱怨。商店生态是 Deepin 的优势，把"安装来源识别"这一环补上，
这类"影子程序"问题基本可以根治。也欢迎其他朋友补充自己遇到的同类案例 —— 尤其是那些"用着正常、其实装了两份"的情况。