开发机包管理器基线
一台新开发机最容易犯的错误，不是少装了一个软件，而是不知道软件从哪里来、由谁安装、以后由谁升级。手工安装包、系统包管理器、用户级包管理器和企业软件中心可以同时把同名命令放进 PATH；今天运行正常，下一次升级却可能切换到另一份二进制、另一套配置和另一位文件所有者。
包管理器基线要解决的是软件生命周期和供应链责任，而不是维护一张“必装软件清单”。Windows 上的 WinGet、Scoop 与 Chocolatey，macOS 和 Linux 上的 Homebrew，Debian/Ubuntu 系的 APT，以及 Fedora/RHEL 系的 DNF 都遵循同一条工程证据链：确认来源和包身份，以合适权限安装，验证真实路径，控制升级，最后能够卸载、回退并解释残留物。
source、repository、bucket 和 tap 是分发入口，不等于目标软件厂商。pin、hold、preferences 和 versionlock 是兼容窗口，不等于永久冻结。代理连通、TLS 成功和包签名又是三层不同证据。把这些概念连起来，开发机软件才从“个人安装结果”变成团队可审计资产。
排查或初始化一台机器时，先确认系统、CPU 架构、账号和已有命令来源。Windows 使用普通 PowerShell，macOS/Linux 使用普通用户 shell；只有修改系统状态的单个动作才提权，不要把管理员终端或 root shell 当作默认工作环境。
[System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture
[System.Runtime.InteropServices.RuntimeInformation]::ProcessArchitecture
whoami
Get-Command winget, scoop, choco -ErrorAction SilentlyContinue |
Select-Object Name, Source, Versionuname -srm
id
command -v brew apt-get dnf 2>/dev/null预期结果不是“至少找到一个包管理器”，而是能够回答：它由系统、用户目录还是企业镜像提供；当前进程架构是否与机器一致；安装动作会写入用户目录还是系统目录；是否会触发 UAC 或 sudo。同一平台同时保留多个包管理器可以是有意设计，但必须为每一类软件定义唯一 owner，不能让多个工具竞争升级同一软件。
实验时选择一个体积小、无后台服务、可安全卸载的 CLI，并使用占位包名 <test-package> 代替盲目照搬。团队应先在隔离测试机确认该包不会覆盖系统组件。
包管理器的能力边界应从项目入口核对：WinGet管理应用与来源；Scoop采用用户目录、manifest 与 bucket；Chocolatey面向传统 Windows 安装器和企业仓库；Homebrew区分 formula、cask 与 tap；APT和 DNF管理发行版软件事务。具体版本、镜像 URL、插件与命令默认值会变化，因此每次形成开发机基线都要同时保存客户端版本和 help 输出。
WinGet Community Repository、Chocolatey Community Repository、Homebrew 第三方 tap、Scoop 社区 bucket 以及发行版第三方 repo 都只是可访问的分发入口，不自动代表目标软件厂商，也不自动满足企业许可、安全和更新时效要求。一次合格安装至少记录包 ID、来源 URL、维护主体、上游下载地址、签名或哈希机制和内部批准状态。
Windows：先决定系统级还是用户级
winget 适合 Windows 官方客户端入口和按精确包 ID 的生命周期管理。先确认客户端与来源，再搜索目标；不要从模糊名称直接进入安装。
winget --version
winget source list
winget search --id <publisher.package> --exact
winget show --id <publisher.package> --exact --source winget
winget install --id <publisher.package> --exact --source winget预期看到精确 ID、来源、版本和安装器信息；安装阶段可能由上游安装器触发 UAC。若 source list 中存在企业源，应显式指定 --source，避免同名包从优先级不同的来源解析。winget source add/remove/reset 会改变共享来源状态，需要管理员权限和变更记录。
Scoop 默认把便携式应用安装到用户目录，适合不希望污染系统目录的 CLI。先审查 bucket，再安装：
scoop --version
scoop bucket list
scoop search <test-package>
scoop info <test-package>
scoop install <test-package>预期 info 能显示 manifest 来源、版本、主页和下载信息，安装后命令由 Scoop shim 解析。--global、非便携安装或修改系统状态可能需要提权；不要为了统一路径把所有软件都改成全局安装。添加 bucket 前要审查仓库 owner、manifest 维护记录、下载 URL、哈希、更新方式和删除后的退出路径。
Chocolatey 默认按管理员方式安装，适合受控 Windows 镜像、企业仓库和需要传统安装器的场景：
choco --version
choco source list
choco search <test-package> --exact
choco info <test-package> --source=<approved-source>
choco install <test-package> --source=<approved-source>预期输出显示包版本和明确来源，安装成功后仍要检查真实二进制路径。社区包可能执行维护者编写的安装脚本；“在 Chocolatey 上可安装”不等于软件厂商发布或企业批准。生产化团队应使用内部 NuGet 源、审核后的包提升流程和留存策略，而不是让所有开发机直接信任社区源。
macOS/Linux：区分用户工具与系统事务
Homebrew 使用 formula 安装构建型软件、使用 cask 管理上游预编译应用、使用 tap 扩展仓库。先检查环境与来源：
brew config
brew tap
brew search <test-package>
brew info <test-package>
brew install <test-package>预期 brew info 显示来源 tap、版本、依赖和安装状态。Homebrew 默认前缀完成初始权限设置后，日常操作通常不需要 sudo；看到要求持续用 sudo brew ... 时，应先检查前缀 owner，而不是扩大权限。企业将 Git remote 指向镜像时，相当于把 Homebrew 本体级别的信任交给镜像维护者，必须有同步、审计和退出方案。
APT 与 DNF 修改系统软件数据库，默认属于需要 sudo 的系统事务。APT 在人工交互中可使用 apt，脚本和初始化程序优先使用更稳定的 apt-get、apt-cache 接口：
sudo apt-get update
apt-cache search <test-package>
apt-cache show <test-package>
apt-cache policy <test-package>
sudo apt-get install <test-package>apt-get update 成功应更新所有批准来源的元数据且没有签名错误；apt-cache policy 应显示候选版本来自预期 repository。现代来源优先使用 /etc/apt/sources.list.d/*.sources 的 Deb822 格式，并用专属 keyring 配合 Signed-By，不要用 trusted=yes 绕过签名。
dnf repolist
dnf repoinfo <approved-repo>
dnf search <test-package>
dnf info <test-package>
dnf repoquery <test-package>
sudo dnf install <test-package>预期 repoquery 能说明候选包的版本、架构和仓库。使用第三方 .repo 文件前，应校验仓库 URL、GPG key、启用范围和 owner。--downloadonly 只证明文件下载，并不证明离线机器具备完整依赖、签名验证和安装闭环。
来源配置是信任配置
团队不要只保存“安装命令”，而应维护来源清单。每条来源至少包含：平台、工具、名称、URL、维护主体、签名或哈希验证方式、代理路径、同步 SLA、保留策略、owner 和撤销方法。个人开发机允许的来源应是这份清单的子集。
WinGet 企业源可标记为 explicit，使调用者必须显式传入 --source；Chocolatey 内网源应成为批准包的唯一上游；Scoop bucket 和 Homebrew tap 应固定到团队审核的仓库；APT 使用独立 keyring 与 Signed-By；DNF 的 repo 文件应显式配置 GPG 校验。禁止用关闭 TLS、签名或 GPG 校验来解决“仓库暂时不可用”。
版本约束不是永久冻结
版本锁定用于给兼容验证争取时间，不是逃避升级。不同工具使用不同机制：
winget pin --help
winget pin add --id <publisher.package> --version <allowed-version-range>
winget pin list
scoop help
scoop hold <test-package>
scoop status
choco pin add --name=<test-package> --version=<approved-version>
choco pin listScoop 的锁定命令必须先由目标版本 scoop help 证实；若当前版本不支持 hold，不要伪造兼容能力，应改用受控 manifest/bucket 提交和版本化开发机镜像。Homebrew 的 brew pin <formula> 仅适用于已安装 formula，不应外推到 cask、tap 或其他下载器。
brew pin <formula>
brew list --pinned
sudo apt-mark hold <package>
apt-mark showhold
dnf versionlock --help
sudo dnf versionlock add <package>
dnf versionlock listAPT 还可通过版本选择和 apt_preferences 定义更细的候选优先级；DNF 的 versionlock 依赖插件，应先确认命令存在。每条锁定记录必须带原因、批准人、版本范围、创建时间、复审日期和安全例外；发现高危漏洞或上游停止支持时，要进入例外评审，不能让 pin/hold 阻断安全修复。
配置分层与可提交边界
包来源基线和允许版本范围可以进入团队文档或开发机初始化仓库；代理密码、仓库 Token、客户端证书私钥和个人配置不能提交。配置模板只保留 https://packages.example.com/...、<username> 和 <token> 等占位符，真实凭证由操作系统凭据库、企业软件代理或短期身份系统注入。
最小验证必须覆盖完整生命周期，而不是只运行 --version。在隔离开发机或临时虚机中选择经批准的 <test-package>，按以下顺序执行。
列出来源：保存 source/repository/bucket/tap 的名称、URL 和信任主体。搜索并查看详情：确认精确包 ID、目标架构、候选版本和来源，避免同名包抢占。安装并验证归属：安装后同时检查版本和二进制真实路径。
检查升级而不盲目全量升级：确认哪些包可升级、候选来自哪里、是否受锁定规则影响。建立版本约束：添加 pin/hold/versionlock，证明列表中可见，并记录到期条件。卸载测试包：复查命令、服务、配置、缓存和锁定记录，确认没有误删共享数据。
Windows 可使用：
Get-Command <test-command> | Select-Object Name, Source, Version
winget list --id <publisher.package> --exact
winget upgrade --id <publisher.package> --exact
scoop status
choco outdated --source=<approved-source>macOS/Linux 可使用：
command -v <test-command>
type -a <test-command>
brew outdated <formula>
apt-cache policy <package>
dnf check-update <package>成功标准是：命令解析到预期包管理器拥有的路径；安装版本与来源记录一致；升级候选来自批准源；锁定规则可见；卸载后测试命令消失或回到已知的另一份安装，而不是留下不可解释的 shadow copy。
安全清理只针对本次测试对象：
winget uninstall --id <publisher.package> --exact
scoop unhold <test-package>
scoop uninstall <test-package>
choco pin remove --name=<test-package>
choco uninstall <test-package>brew unpin <formula>
brew uninstall <formula>
sudo apt-mark unhold <package>
sudo apt-get remove <package>
sudo dnf versionlock delete <package>
sudo dnf remove <package>APT 的 remove 通常保留配置，purge 会进一步删除包配置；二者必须按实验边界选择。不要把清空整个 Homebrew、Scoop、Chocolatey、APT/DNF 缓存或删除全局仓库配置写进单包清理。缓存可能被其他项目复用，来源和 keyring 也可能是团队共享基线。
上述命令是基于官方能力设计的可复现实验，当前会话未实际安装或卸载测试包。读者应在非生产开发机先确认占位符、命令帮助和包的卸载影响。
操作系统包管理器不应偷偷成为项目构建的隐式依赖。项目仓库至少应声明“需要哪些系统级工具、由哪些平台入口提供、怎样证明版本”，而不是假设开发者已经手工装好。
推荐在仓库中维护不含凭证的开发机基线：
docs/development/workstation.md
scripts/bootstrap/windows.ps1
scripts/bootstrap/macos.sh
scripts/bootstrap/linux.sh
scripts/verify-toolchain.ps1
scripts/verify-toolchain.sh初始化脚本应先探测、再显示计划、最后安装，避免启动时执行全量升级。每个包使用精确 ID 或来源，并把“工具可执行路径 + 版本 + 进程架构”写入验证脚本。无法由项目控制的企业软件，应在文档中指向软件中心或申请流程，不要绕过管理策略改装个人版本。
对于需要强可复现的构建，系统包只负责提供最小引导工具；JDK、Node.js、Python 等运行时交给版本管理和项目声明，项目依赖交给 lockfile 或 wrapper，构建产物交给制品仓库。这样可以缩小“开发机升级一个系统包导致整个项目变化”的爆炸半径。
日常维护应围绕“盘点、评估、单项变更、再验证”展开：
winget source list
winget list
winget upgrade
scoop bucket list
scoop status
choco source list
choco outdatedbrew tap
brew outdated
apt list --upgradable
apt-mark showhold
dnf repolist
dnf check-update
dnf versionlock list列表命令用于生成变更计划，不等于批准执行。团队升级一次只处理明确范围：先阅读上游变更和安全公告，在测试机执行单包升级，运行项目验收，确认配置和 PATH 没漂移，再扩大到受管开发机。全量 upgrade 不应作为登录脚本、每日任务或新机初始化的默认动作。
离线环境需要独立闭环：联网区从批准源解析完整依赖并下载，记录包、版本、架构、摘要、签名和来源；通过受控介质进入隔离区；离线仓库重新建立元数据和签名验证；目标机从内网源完成安装、升级、卸载和审计。只复制一个安装文件，或使用 DNF --downloadonly，都不能证明依赖和信任链完整。
搜索到了包，安装的却不是预期来源
名称相同但 publisher、版本或下载地址异常，或不同机器安装结果不一致。第一证据是 winget show --source、scoop info、choco info --source、brew info、apt-cache policy 或 dnf repoquery。若精确 ID 和来源与基线不符，先停止安装；检查源优先级、同名包和第三方仓库。修复后重新执行 show/info，再安装并核对真实路径。
元数据成功，下载阶段出现 407 或 TLS 错误
搜索可用，但安装报 407 Proxy Authentication Required、证书颁发者未知或超时。先保存目标 FQDN、状态码、证书错误类别和当前来源，不记录代理密码。407 优先检查该工具的代理认证；证书链错误检查企业 CA 是否进入该下载器实际使用的信任库。禁止用 --insecure、trusted=yes、--nogpgcheck 或关闭证书校验作为长期修复。修复后重复“元数据读取 + 包下载 + 签名验证”三步。
安装成功，新终端仍解析到旧版本
安装日志成功，但 --version 未变化。使用 Get-Command ... -All 或 type -a 列出全部命令路径，检查 shell hash、shim、旧安装目录和进程架构。只有在确认目标安装路径后才调整 PATH；重新打开终端并执行项目验证，不能靠删除未知目录碰运气。
普通用户无法升级或卸载
提示 Access denied、权限不足、前缀不可写或文件被占用。先确认包最初由用户级还是管理员方式安装，并检查文件 owner；不要直接递归放开权限。使用与原安装相同的权限边界执行单项事务，关闭占用进程，再验证普通用户环境未被管理员生成的缓存或配置污染。
锁定规则让安全修复长期无法进入
升级列表长期不出现目标包，或高危漏洞版本仍被 pin/hold/versionlock。先列出所有锁定并匹配 owner、原因和复审日期。无责任人或已过期的锁定应进入变更评审；在测试环境解除、升级并跑兼容验证，通过后按批次推广。不要在所有机器直接移除全部锁定。
离线安装缺依赖或签名无法验证
联网机下载成功，隔离机提示依赖缺失、架构不符、key 不存在或元数据过期。第一证据是离线包清单、目标 OS/架构、仓库元数据和签名日志。重新在与目标环境一致的解析环境生成完整仓库；不能靠逐个拷包或关闭签名校验修补。
代理配置存在多个层次。WinGet 支持单次命令的 --proxy / --no-proxy；Chocolatey、Scoop、Homebrew、APT 和 DNF 可能读取各自配置、环境变量或底层下载器。设置了操作系统代理，不能证明所有包管理器已经继承。团队验收应分别完成“读取元数据、下载包、校验签名”三个动作。
代理 URL 中的用户名和密码、仓库 Token、客户端证书私钥不得写入脚本、命令历史、截图或仓库。优先使用企业透明代理、系统凭据库、短期令牌和受控配置注入；确需文件配置时限制 ACL，并定义轮换与撤销。示例统一使用 https://packages.example.com 和 <token>，不能复制真实内网地址。
权限模型遵循三条规则：用户级工具由普通用户拥有；系统软件事务按单个命令提权；来源、keyring 和企业代理配置由指定管理员维护。winget 来源变更、Chocolatey 默认安装、APT/DNF 系统事务和部分全局安装可能需要管理员权限，但这不意味着日常 shell 应长期提权。
仓库签名和 TLS 解决不同问题：TLS 保护传输端点，GPG、安装器签名或 manifest 哈希帮助验证内容来源与完整性。企业 HTTPS 检查 CA 只能由安全团队提供并核验指纹；它不能替代包签名，也不能证明社区包等于厂商官方发行。
架构师应把包管理器看成开发机供应链入口，为每个平台建立一份可审计基线：
| 治理对象 | 最低要求 | 验收证据 |
|---|---|---|
| 工具选择 | 每类软件只有一个安装与升级 owner | 平台与包类型映射表 |
| 来源准入 | 记录 URL、维护主体、签名、同步和退出方式 | 批准来源清单与变更记录 |
| 版本基线 | 允许范围、兼容验证、升级窗口和安全例外 | pin/hold/versionlock 清单与复审日期 |
| 权限 | 用户级、系统级和管理员动作边界明确 | 安装路径、owner 与提权记录 |
| 内网与离线 | 元数据、依赖、签名、审计和卸载闭环 | 离线仓库清单与隔离机验证报告 |
| 生命周期 | 安装、升级、回退、卸载和残留归属明确 | 开发机验收脚本与退役记录 |
开发机镜像 owner 负责基线和初始化脚本，安全团队负责来源信任与 CA，平台团队负责内网镜像、同步 SLA 和可用性，项目 owner 负责兼容验证，终端用户只在批准范围内执行安装。任何临时第三方源和版本锁定都必须有到期时间；人员离职、项目退出或工具替换时，要回收凭证、删除无主来源并验证替代路径。
多包管理器争抢同一软件
典型现象是 winget list、Chocolatey 与 Scoop 都记录同名工具，而终端解析到其中另一份。判断标准不是“版本最新”，而是包 owner、真实路径和升级责任是否唯一。基线应明确某类工具由哪个入口管理；迁移时先盘点依赖和配置，卸载旧入口后重新验证，避免直接删除二进制造成卸载数据库失真。
内网镜像把公网风险变成内部盲区
镜像可降低公网不稳定，却同时获得供应链权力。若没有同步延迟、签名校验、包保留、恶意版本撤销和 owner，开发机可能长期安装过期或被替换的包。验收至少比较上游版本、内部摘要和签名状态；同步超出 SLA 或摘要不一致时停止推广，而不是让用户临时切回任意公网源。
社区 manifest 与厂商发布脱钩
社区仓库维护者可能更新下载 URL、静默参数或校验值，软件厂商却未参与。出现发布者不一致、上游 URL 跳转、哈希频繁变化或安装脚本扩大权限时，应冻结该包并人工审查。可接受的取舍是将审核后的包提升到内网源，并保留上游出处；不可接受的是用“社区热门”替代发布主体证明。
版本冻结与安全修复冲突
长期 pin 能稳定构建，也会积累漏洞和不可跨越的升级跨度。判断标准包括锁定年龄、上游支持状态、漏洞严重度和项目兼容测试结果。每条锁定必须有退出条件；高危修复无法进入时，架构师需要在“兼容风险”和“暴露风险”之间形成书面决策，而不是默默延长冻结。
全量升级缺少可逆边界
一次全量 upgrade 可能同时修改运行时、编译器、Git、容器客户端和证书组件，失败后难以归因。团队应按包和项目建立升级批次，保留变更前清单、安装物或可重建镜像，并定义回滚触发条件。包管理器缺少原生降级能力时，回滚方案应是恢复已验证镜像或从批准仓库安装指定旧版本，而不是依赖缓存“也许还在”。
离线闭环只有下载，没有治理
真正的离线能力必须覆盖依赖闭包、架构、签名、介质交接、内网元数据、安装、升级和卸载。若每次靠个人 U 盘和临时命令补包，系统就没有可审计供应链。目标不是让隔离机“装上一次”，而是让同一批包可重复安装、可验证、可撤销，并知道何时过期。
当前包管理器、版本、CPU 架构和真实可执行路径已经记录。每个平台的软件类型都有唯一安装与升级 owner，没有多个包管理器争抢同一软件。source、repository、bucket 和 tap 的 URL、维护主体、签名或哈希机制已经核验。
社区仓库与软件厂商官方发行已明确区分，没有以“可搜索到”代替信任审批。已用精确 ID 和明确来源完成 search、show、install、upgrade 检查与 uninstall 闭环。安装后的版本、路径、进程架构和文件 owner 符合预期。
pin、hold、preferences 或 versionlock 有原因、owner、复审日期和安全升级出口。代理和企业 CA 已分别验证元数据读取、包下载与签名校验，未关闭 TLS/GPG 校验。内网源有同步 SLA、保留、撤销、审计和公网源退出策略。
离线环境验证了完整依赖、架构、摘要、签名、安装、升级和卸载，不只是下载文件。初始化脚本不会默认全量升级，不包含真实凭证或内部地址。清理只作用于测试包及其明确残留，不删除共享缓存、全局来源或未知配置。
每个目标平台、企业代理和离线环境都有独立运行证据，文档描述没有替代现场验证。