统信UOS提示“依赖关系不满足”需四步分层处理：一、执行sudo apt --fix-broken install强制修复半配置包；二、清理缓存并更新索引；三、根据错误提示手动安装缺失包或离线安装匹配架构.deb包；四、切换Deepin社区源扩展依赖供给。
统信UOS安装软件时提示“依赖关系不满足”“未满足的依赖关系”或“E: 无法修正错误”，说明APT在解析目标包及其依赖链时，发现当前启用的软件源中缺少对应名称、版本或架构匹配的安装单元，必须按状态分层处理才能恢复安装能力。
强制修复中断的依赖状态
这一步是90%依赖报错的首解动作，它会扫描所有标记为 half-configured、unpacked 或 triggers-awaited 的包，并尝试从当前源自动补全依赖完成配置。
打开终端（Ctrl + Alt + T）→ 执行 sudo apt --fix-broken install。
当提示“您希望继续执行吗?[Y/n]”时，必须输入大写 【Y】 并回车——部分系统严格区分大小写，输小写 y 会导致命令静默退出且无任何提示。
等待终端输出“正在设置 xxx”或“依赖关系已修复”后结束，期间可能静默数秒，属正常现象，切勿中断或关闭窗口。
清理缓存并重载软件源索引
过期或损坏的 .deb 缓存和陈旧的 Packages.gz 元数据会污染依赖树计算逻辑，导致APT误判可用包集合，进而触发虚假冲突。
执行：sudo rm -rf /var/cache/apt/archives/*.deb && sudo apt clean && sudo apt update。
观察输出末尾是否出现“正在读取软件包列表 完成”。若仍有 Ign 或 Err 行，说明软件源地址失效，需立即跳转至“切换Deepin社区源”步骤处理。
这一步操作起来很简单，直接把整条命令复制粘贴进去就行。
手动补全关键缺失依赖包
当错误信息明确指出缺失具体包名（如“libtinfo6 依赖于 libc6 (>= 2.34)”），且 --fix-broken install 无法定位时，需人工介入补全依赖链环节。
方法一：直接安装报错中列出的包名
例如提示缺失 libc6，则执行：sudo apt install libc6。
方法二：清除残留配置再重装
若安装失败并提示“已卸载但配置残留”，先运行：dpkg -l | grep "^rc" | grep libc6；如有输出，说明该包残留干扰新安装，执行：sudo dpkg --purge libc6，再重试安装。
方法三：离线安装指定架构 .deb 包
确认本机架构：uname -m（返回 amd64 或 aarch64）→ 在联网设备下载匹配包（如 libtinfo6_6.4-1_amd64.deb）→ 拷贝至 UOS → 终端进入该目录 → 执行：sudo dpkg -i libtinfo6_*.deb → 紧接着必须再运行 sudo apt --fix-broken install 收尾，否则依赖链仍不完整。
切换为Deepin社区源扩展依赖供给
统信UOS默认源出于稳定性考虑，长期不更新开发类库（如 qtbase5-dev、libgl1-mesa-dev）或基础运行库（如 libssl1.1、libicu70），而Deepin社区源与UOS同源，提供更及时、ABI兼容的包更新。
第一步：备份当前源配置，防止误操作后无法恢复：sudo cp /etc/apt/sources.list /etc/apt/sources.list.uos-bak。
第二步：添加Deepin社区源（适用于UOS V20 SP1及之后版本）：
sudo sh -c "echo 'deb https://packages.deepin.com/deepin/ apricot main non-free contrib' > /etc/apt/sources.list.d/deepin.list"。
第三步：更新索引并安装目标库：sudo apt update && sudo apt install libssl1.1 libicu70 libpng16-16；若提示冲突，先执行 sudo apt --fix-broken install 再重试。
绕过签名验证解除安装拦截
当双击.deb无响应、终端报错65280或提示“failed the verification”，说明 deepin-elf-verify 服务正在主动拦截未签名包安装。
执行：sudo sed -i 's/enable_signature_check=true/enable_signature_check=false/g' /usr/share/sec-policy/app-control.conf。
然后重启服务：sudo systemctl restart sec-policy-app-control.service。
这一步修改的是应用层签名检查策略，不影响内核级安全防护，重启服务后立即生效。
