企业官网建设流程全解析

1. WinGet 到底是什么，为什么你需要尽快掌握它

我第一次接触 WinGet，是给一台新电脑装环境的时候。当时要在命令行里装 Python、装 Git、装 Node.js，还得一个个去官网下载安装包，点完“下一步”再点“完成”，一套流程折腾下来至少半个钟头。后来同事甩给我一句话：“你试试 winget install python.git”，我当场愣住了——窗口里啪的一下，软件就开始下载安装，全程不需要打开浏览器，不需要找镜像站，不需要手动点安装向导。

这就是 WinGet，全称 Windows Package Manager，微软官方出品的 Windows 包管理器。你可以把它理解成 Windows 上的“应用商店命令行版”——一条命令装软件，一条命令更新软件，一条命令卸载软件，而且安装的是官方源里的正式版本，不会像某些下载站那样给你捆绑全家桶。

这篇文章我打算从一个实际使用者的角度，把 WinGet 从下载到日常使用中最容易踩坑的几个环节完整过一遍，包括离线安装包怎么搞、中科大源怎么配、claude code 这类第三方工具怎么装、以及“系统里没有 WinGet 怎么办”这类高频问题怎么处理。不管你之前用过没有，跟着走一遍，基本就能独立上手了。

WinGet 适合谁？说实话，适合所有在 Windows 上折腾软件的人。程序员可以用它管理开发环境，普通用户可以用它批量装常用软件，网管和运维可以用它做批量部署。它解决的核心痛点就三个：下载软件去官网太麻烦、安装软件手动点向导太费时、批量装软件没有统一的命令行方案。

从 2020 年微软发布 WinGet 1.0 开始，这个工具已经迭代了好几年。现在它预装也在 Windows 10 1809+ 和 Windows 11 里，但很多精简版系统或企业定制版不一定带，所以“怎么下载安装 WinGet”这个问题，到现在依然是高频搜索词。

2. WinGet 的运行环境与版本选择

2.1 系统版本和前置条件

WinGet 使用的是 Microsoft Store 的 App Installer 框架，所以它对系统有一个基本要求：Windows 10 1809 以上或者 Windows 11。早于这个版本的，比如 Windows 7、Windows 8.1，基本就别想了，WinGet 官方不支持，强行装也没法正常用。

还有个很容易被忽略的点：WinGet 依赖一些现代 Windows 组件，比如 App Installer 的框架包、VCLib 运行库等。如果你的系统是精简版、LTSC 或者某些“优化版”，这些组件可能被砍掉了，这时候即便装了 WinGet 也会出现“无法找到 App Installer”或者“执行 set-msi 时出错”等奇怪毛病。

怎么确认系统版本？按 Win+R 输入winver回车，对话框里会显示版本号和系统版本号。只要是大版本 1809 及以上，基础就能用。如果还是更老的系统，建议优先升级系统，不然就算折腾出 WinGet，很多新软件的新版本也装不上。

2.2 WinGet 的版本概念：客户端版本 vs 软件清单版本

这里必须拎清一个概念：WinGet 本身是一个客户端程序，它负责解析命令、下载安装包、执行安装逻辑；而它能装哪些软件，靠的是背后的软件仓库清单。这两者经常被人搞混。

你本地 WinGet 的版本，决定的是客户端本身的功能，比如是否支持某些安装参数、是否有新的命令语法。而软件仓库清单，也就是微软维护的 winget-pkgs 仓库，决定的是你能搜到哪些软件。清单更新非常频繁，基本每天都有新软件合入。

所以你遇到了“搜不到某个软件”的情况，不一定是你 WinGet 版本太低，也可能是仓库里还没有收录，或者该软件的上架格式不标准。这时候你需要先更新源，再重新搜索。更新源的命令是：

winget source update

这个命令会同步最新的软件清单到本地索引。

2.3 离线环境下的 WinGet 安装包准备

离线安装 WinGet 是另一个高频场景。很多企业内网、机房机器不能连外网，或者网速极差，这时候“WinGet 离线安装版本”就成了刚需。

官方推荐的方式是安装“应用安装程序”包，也就是 App Installer。你可以去 Microsoft Store 的官方页面，或者通过一些离线包下载工具，拿到对应架构的 .msixbundle 文件。架构选择很简单：绝大多数现代电脑是 x64，老一些的可能是 x86，ARM 设备如 Surface Pro X 则选 arm64。

安装离线包的命令是：

Add-AppxPackage -Path "C:\path\to\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"

注意，这个命令要在 PowerShell 里以管理员身份运行。如果不带管理员权限，大概率会报“部署失败，因为未启用 Developer Mode”或者“拒绝访问”之类的问题。

还有一个细节：这个 .msixbundle 文件不是只装一个就完事，它通常是一堆依赖包的合集，如果系统缺少某些依赖，比如 Microsoft.VCLibs，会安装失败。你可以同样从网上下载对应的 VCLibs 包，用Add-AppxPackage按顺序安装。顺序一般是：VCLibs → UI.Xaml → AppInstaller。

3. WinGet 的常见安装方式与具体流程

3.1 在线安装：最快但最容易被忽略的坑

如果你的系统已经预装了 App Installer，那 WinGet 是直接可用的——在命令行里敲winget --version能看到版本号，就说明已经在了。

如果没有，最简单的在线安装方式是打开 Microsoft Store，搜索“应用安装程序”直接安装。这种装法有个特点：它会自动处理依赖，装完就能用。缺点也有——如果你的系统区域设置不对，或者 Store 服务被策略禁用，就会卡在下载阶段不动。

在命令行里也可以装，不过限制比较多。PowerShell 5.1 里执行：

Start-Process "ms-windows-store://pdp/?ProductId=9NBLGGH4NNS1"

这会唤起应用商店的安装页，剩下的还是要手工点一下。严格意义上这不算全命令行安装，但它解决了“找不到入口”的问题。

3.2 从 GitHub Releases 手动安装（适合网络能通 GitHub 的场景）

WinGet 的客户端安装包发布在 microsoft/winget-cli 的 Releases 页面。这里面有几种包格式：.msixbundle、.msi、.exe 等。

我建议重度使用者在网络条件允许时，直接下载 .msixbundle 安装。理由是这个包跟 Store 渠道完全一致，后续升级路径清晰，winget upgrade也能正常接管自动升级。

下载时注意看名称，比如Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle这个文件，就是包含了 x86、x64、arm64 三种架构的合包。单独下载一个也行，尽量选合包，免得在架构判断上出错。

下载完成后，在解压目录打开 PowerShell，执行：

Add-AppxPackage -Path ".\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"

执行完看到彩色进度条跑完，没有红色报错，就成功了。验证方式：

winget --version

如果能输出版本号，比如v1.7.10582，那就说明 WinGet 已经可以用了。

3.3 使用命令安装 WinGet（适合喜欢命令行的用户）

如果你的系统支持 App Installer 框架，还可以通过命令触发安装逻辑。先打开 PowerShell，然后执行：

Add-AppxPackage -Path "https://aka.ms/getwinget"

这个 URL 是微软官方维护的指向最新 WinGet 安装包的短链接。直接从远程路径安装，不需要提前下载到本地。这个方法我记得写在微软官方文档的“手动安装”章节里，实测网速好的情况下非常省事。

但这招对网络要求比较高，如果公司防火墙把微软 CDN 封了，或是网速太慢，就很容易让 PowerShell 卡在“部署操作进度”半天不动。这时候我还是建议退回 3.2 的方法——先下到本地再装。

3.4 中科大源：国内下载慢的弯道超车方案

很多人第一次用 WinGet 下载软件时发现速度感人，尤其是 GitHub 上托管的那部分安装包，动辄几 KB 每秒，急死人。这时候国内几个高校镜像源就很实用，其中“中科大源”用得比较多。

先说原理：WinGet 的软件安装包并不都托管在微软服务器上，有相当一部分直接链接到软件厂商的官网，比如 Python 从 python.org 下载、Git 从 github.com 下载。国内直连这些地址的速度不稳定，所以 WinGet 支持配置镜像源，把请求转发到中科大等高校的 AOSP 和 GitHub 代理镜像上。

配置中科大源的方式，是修改 WinGet 的源设置。先看当前源列表：

winget source list

输出里能看到默认源winget，来源是https://cdn.winget.microsoft.com/cache/。要给它加一个镜像，你需要编辑配置文件，路径一般在：

%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft\WinGet\Settings\settings.json

如果没有这个文件就新建一个，然后写入类似的配置结构：把Source项下的镜像 URL 替换为中科大的地址。不过要注意，不同版本的字段结构略有差异，老版本字段是"Source": { "AutoUpdateIntervalInMinutes": 3, "Agreements": {} , "Network": { "Mirror": { "Default": "" }}}。写完后保存，重启终端，再执行winget source list就能看到镜像生效了。

必须强调一下：中科大源主要缓存的是某些大文件，不是所有包都有加速效果。你装某些冷门软件时，它还是去官方源拉取，这是正常的，不是配置错了。

3.5 从 pip、npm 的角度理解 WinGet 的包管理逻辑

如果你接触过 pip 或者 npm，WinGet 的世界并不难懂。pip install requests是从 PyPI 下载安装，winget install Python.Python.3.12则是从 winget 源里找到 Python 的安装包并执行安装。

从设计逻辑来看，WinGet 有个核心文件叫 manifest，每个软件都有一段 YAML 格式的清单，描述了这个软件叫什么名字、什么版本、哪个发行者、安装包在哪、安装参数是什么。WinGet 的“搜索引擎”就是在一堆这样的 manifest 里找匹配项。

这就解释了为什么有些软件在 WinGet 里能装，有些不能——没上清单的，WinGet 里自然搜不到。也解释了为什么 WinGet 安装时会偶尔弹 UAC 授权框——因为 manifest 里声明的安装程序是 exe，WinGet 只是帮你把它跑起来，那些安装程序的 UI 你还是得看着。

4. WinGet 核心使用场景全实操

4.1 搜包、装包、卸包的基本命令

日常使用频率最高的几条命令不多，记住这几个基本就能干活了。

搜索一个包：

winget search python

输出结果会列出所有名字或描述里包含 python 的软件，比如 Python.Python.3.12、Python.Python.3.11，还有 Anaconda.Anaconda3 等。每个条目有 ID、名称、版本、源。ID 是安装时的唯一标识，尽量用 ID 而不是用名字来装，因为名字可能会匹配到多个软件。

安装一个包：

winget install --id Python.Python.3.12 -e --source winget

参数说明：--id指定软件 ID，-e表示精确匹配，--source winget指定源。这样写的好处是不用怕匹配错误——如果你只用winget install python，WinGet 可能会弹出一堆候选让你选，反而不方便。

静默安装参数：

winget install --id Git.Git -e --silent

--silent会让安装程序不弹出任何界面。这是批量部署场景的核心参数。不过要留意，不是所有软件都支持静默安装，某些软件可能“静悄悄装完之后什么都没有”，还有某些国产软件即使支持静默安装，也会依然弹窗广告。所以一般建议第一次手动装，确认没问题后再用脚本批量装。

卸载一个包：

winget uninstall --id Python.Python.3.12 -e

卸载命令在部分软件上会失灵——某些自带的卸载程序写得不好，或者被安全软件拦截，这时候 WinGet 会报“无法找到卸载程序”之类的错误。先检查是不是管理员权限没给够，再检查是不是软件本身还在运行或占用文件。

4.2 批量安装开发环境的一行命令实操

WinGet 最舒服的场景是“一条命令装齐一套环境”。我举个例子，新电脑配置前端开发环境，传统方式要装 Node.js、Git、Visual Studio Code、Google Chrome、Postman、Docker Desktop，这六个软件放在以前，手动装少说一小时。

用 WinGet 是这样：

winget install --id OpenJS.NodeJS.LTS -e --silent winget install --id Git.Git -e --silent winget install --id Microsoft.VisualStudioCode -e --silent winget install --id Google.Chrome -e --silent winget install --id Postman.Postman -e --silent winget install --id Docker.DockerDesktop -e --silent

把这些写成一个.ps1或.bat脚本，以后给新机器部署时直接跑一遍就行。这一步省下来的时间非常可观。而且因为安装了官方版本，不会再出现“我明明装了 Python 为什么命令提示 python 找不到”这种环境变量路径不一致的问题。

再分享一个小技巧：先用winget list查看已安装软件，再写脚本时就能避开重装。比如判断 Docker 已经在的时候，脚本可以直接跳过它。不过这属于锦上添花的玩法，新手暂时不用纠结。

4.3 更新、升级、自动更新的实际体验

保持软件版本最新，WinGet 同样能管。查看哪些软件有新版：

winget upgrade

这条命令会列出当前系统里可升级的软件，通过它你能一目了然地看到有大版本更新的是谁。

全量升级：

winget upgrade --all

这条命令会把所有可升级的软件都装一遍新版本。听着很爽，实际用起来有一个坑：有些软件升级后需要重启系统才能生效，有些升级会改变文件路径导致快捷方式失效。

另外注意：winget upgrade --all不是万能的。第一，有些软件因为 manifest 没有提供升级检测信息，就算出了新版它也不会出现在升级列表里；第二，某些软件主程序被占用时升级会失败。所以全量升级前，建议先看一遍列表，把重要的软件分开升级。

WinGet 有个“自动升级”能力，但它依赖每次打开 PowerShell 时触发检查。默认情况下，源更新间隔是 180 分钟。如果想让它在每次执行命令前都自动查一遍更新，可以在 settings.json 里把源自动更新间隔调小，比如改成 3 分钟。这个配置是可选的，我一般保持默认，因为频繁请求源也没什么必要。

4.4 Winget 安装 Claude Code 等三方工具的特殊流程

最近 Claude Code 挺火，不少人在命令行里执行过这条命令：

winget install anthropic.claudecode

如果你在 PowerShell 窗口里执行这条命令，出现了类似 “无法找到包”或者“多个包匹配”的提示，不用慌。这可能不是 WinGet 本身的问题，而是这个包的 manifest 需要一个稳定的网络环境才能正确拉到。另外 GitHub 托管的安装包在国内访问不稳，也会导致安装中断。

更稳妥的方法是先去搜索：

winget search claudecode

看返回的 ID 到底是什么。有时候包名不是anthropic.claudecode，而是Anthropic.ClaudeCode之类，大小写和分隔符会变。搜出来后，用：

winget install --id Anthropic.ClaudeCode -e

还有一种情况是 WinGet 太老，导致无法识别新版 manifest 里的一些结构字段。所以如果你发现某个新软件明明已经上架了，但自己却装不上，先跑一遍：

winget upgrade --Self --force

把 WinGet 自身升级到最新版，再重新搜索安装。

4.5 通过 import/export 管理软件清单

这是一个容易被忽略但极其实用的功能：WinGet 支持把当前已安装的软件列表导出成 JSON 文件，再在另一台机器上批量导入安装。

导出：

winget export -o D:\packages.json

导入：

winget import -i D:\packages.json

这两条命令适合什么场景？比如你公司有一台“黄金模板机”，里面装好了所有开发软件和办公软件，现在要给十台新员工电脑快速初始化，就不需要逐台去手动装。把packages.json一拷，每台机器跑一次winget import，剩下就是喝水等待的时间。

实际导入时需要注意：这个 JSON 里记录的是 WinGet 源里的软件 ID，如果某台机器网络受限无法访问这些安装包地址，导入就会有几项失败。另外，如果目标机器上已经装了某软件的高版本，导入时通常不会降级安装，而是直接跳过或报冲突，这属于正常行为，不用过于担心。

5. 使用过程中的高频问题与排查实录

5.1 “无法找到包”和“多个包匹配”的区分处理

这是我被问得最多的一类问题。winget search时能看到，但winget install时提示“无法找到包”，这通常是因为你用-e精确匹配了一个错误的 ID。先用搜索命令把完整 ID 带出来，再复制粘贴到安装命令里，基本能解决。

另一种更常见的情况是安装某个包时，提示 “Multiple packages found matching input criteria”。比如winget install python会同时匹配 Python 3.11、Python 3.12、Anaconda 等一长串。解决方式就是前面说的，用--id参数指定精确 ID。如果不想每次手敲 ID，也可以看一眼输出里的序号，直接winget install --id 序号，不过这个用法我不推荐，换成 ID 更清晰稳定。

值得注意的一个细节是：winget install在有些系统上默认会要求你同意源协议。第一次执行时，它会弹出一段许可协议，你必须输入y确认。如果是在自动化脚本里，建议加上--accept-source-agreements --accept-package-agreements这两个参数，否则脚本会在协议确认处卡住。

5.2 管理员权限和依赖问题导致的安装失败

WinGet 安装软件时报“请求的操作需要提升”是最常见的权限问题。解决方式很直接：把 PowerShell 或终端窗口用管理员身份打开。但有个细节要注意，如果你是在 VS Code 的集成终端里执行，就算 VS Code 本身是以管理员启动的，终端里的命令也不一定继承管理员权限。遇到权限类报错，直接新开一个管理员 PowerShell 窗口再试，是最省心的判断方法。

依赖问题则更隐蔽。比如某些 C++ 运行库依赖、.NET 运行时依赖缺失时，WinGet 可能装完软件后一打开就报缺少 DLL。这类问题 WinGet 的 manifest 里不一定写了依赖关系，WinGet 客户端也不会像 apt 那样自动拉取依赖。解决办法是先把常见的运行库装齐，例如：

winget install --id Microsoft.VCRedist.2015+.x64 -e --silent winget install --id Microsoft.DotNet.Runtime.8 -e --silent

装完再装目标软件，成功率会高很多。

5.3 网络协议和源相关的问题自查

Windows 上如果配置了代理，WinGet 可能会出现“下载失败”的问题，这是因为 WinGet 走的是 WinHTTP 代理设置，而不是系统代理设置（IE 代理/Edge 代理）。你系统能开浏览器上网，不代表 WinGet 就能正常访问网络。

解决方式是：

netsh winhttp set proxy proxy-server="http://your-proxy-ip:port" bypass-list="*.local"

或者，如果确认不想走代理，就还原为直连：

netsh winhttp reset proxy

另外，如果winget source update一直卡住，可以先把源重置一下：

winget source reset --force

重置之后，WinGet 会重新拉取完整的 manifest 索引。这个操作不会影响已安装的软件，只是让本地索引重新同步，遇到源缓存损坏的情况非常有效。

5.4 WinGet 命令提示不是内部或外部命令

你可能会遇到这种情况：在 CMD 里敲winget，提示“不是内部或外部命令”。这通常是因为 WinGet 不在系统的 PATH 环境变量里。正常情况下 WinGet 安装后会自动把%LOCALAPPDATA%\Microsoft\WindowsApps加进 PATH，但这个目录没有正确加入时，CMD 就认不出 winget 命令。

如果是这种情况，一种快速处理方式是直接切换到 PowerShell 里试试。PowerShell 对 App Installer 框架的识别更友好，很多时候 PowerShell 里winget能用，CMD 里不能。如果 PowerShell 里也提示“无法识别”，那就需要检查 WinGet 是否成功安装，也就是回到第 2 节、第 3 节的安装流程，确认安装完成后重新打开终端窗口——新窗口才会刷新 PATH。

5.5 安装目录不是 C 盘？移动软件路径的处理

WinGet 安装的软件默认装什么地方？这是个经常引发疑惑的问题。实际上，WinGet 本身“不决定”安装路径，真正决定路径的是各个软件自带的安装程序。比如 Python 默认装到C:\Python或C:\Program Files，而某些便携版软件会自己解压到临时目录。

想把 WinGet 安装的软件换到 D 盘？这得分情况：

• 支持自定义安装目录参数的安装包，可以使用 WinGet 的--location参数指定，比如：

winget install --id Google.Chrome -e --location "D:\Applications\Chrome"

但这个参数只对部分安装包有效，很多 exe 安装程序根本不接受外部传入的安装路径参数，这个参数就会被忽略。

• 对于不支持自定义路径的软件，只能老老实实装到默认路径，然后用系统自带的应用迁移功能或者目录链接（junction）来做搬家。这类操作有一定风险，不建议新手折腾，尤其是某些软件对安装路径有硬编码注册表项，强制迁移会导致卸载器和更新功能出问题。

5.6 不同用户环境下 WinGet 的行为差异

最后提一个很多人不知道的坑：WinGet 我在管理员账户下能用，但在标准用户下“好像不能用”，这不是错觉。虽然 WinGet 本身是当前用户级别的工具，但安装软件时必须由安装程序触发 UAC 提权。你在管理员账户下用 WinGet，UAC 弹出来点一下“是”就完事；在标准用户下，UAC 会要求输入管理员密码，如果没有管理员配合，安装自然会失败。

如果公司的电脑策略很严格，标准用户下连Add-AppxPackage都执行不了，那 WinGet 安装这一步就直接卡住。所以，要在企业环境里大规模铺开 WinGet 部署，通常需要 IT 先通过 SCCM 或组策略把 App Installer 推到每台机器，再开放必要的执行权限。做不到这一步，用户本地折腾半天也没用。

6. 按使用场景推荐的一组实用配置

6.1 关闭安装协议确认，提升自动化脚本效率

如果你要把 WinGet 写进批处理脚本或者 CI 流水线，每次交互式确认都会卡住任务。建议直接在 settings.json 里开启“静默接受协议”的选项。具体来说，在 settings.json 的"InstallBehavior"段里可以配置"SkipDependencies"等字段，以及在"Telemetry"段中控制是否允许匿名反馈。更重要的是，在命令行参数里统一加上--accept-source-agreements --accept-package-agreements，基本不会再遇到协议卡住的问题。

以我实际经验来说，脚本里不加这两个参数，第一次跑大概率会在“是否接受协议”的地方一直等输入。加上之后顺滑很多，省事。

6.2 可视化查看已装软件和导出清单

有部分人用 WinGet 只是想知道“自己电脑上到底装了哪些软件”。你可以：

winget list

这个列表的含义是“WinGet 认识且能管理的软件”，不包括某些绿色软件、便携软件和系统组件。想看全部已安装软件，还是得去系统自带的“应用和功能”里看。

如果你想把 WinGet 认识的软件清单给别人看，用文本文件导出即可：

winget list > D:\applist.txt

这个不是 JSON 格式，不能用于winget import。要能导入导出的，必须用winget export生成的 JSON 格式。

6.3 结合脚本实现全自动环境初始化

实际工作中，可以把 WinGet 的几个命令组合成一个 PowerShell 脚本：

# 初始化开发环境脚本 winget source update winget install --id OpenJS.NodeJS.LTS -e --silent --accept-source-agreements --accept-package-agreements winget install --id Git.Git -e --silent --accept-source-agreements --accept-package-agreements winget install --id Microsoft.VisualStudioCode -e --silent --accept-source-agreements --accept-package-agreements winget install --id GitHub.GitHubDesktop -e --silent --accept-source-agreements --accept-package-agreements Write-Host "环境初始化完成"

保存为.ps1文件，右键“使用 PowerShell 运行”即可。前提是系统允许执行 PowerShell 脚本，如果你的机器开了执行策略限制，可以先执行：

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

这个设置只对当前用户生效，不需要管理员权限，比较安全。

7. 我对 WinGet 使用的几个独家经验

用了 WinGet 这么久，有几个经验不一定写在哪篇文档里，但解决了我不少实际问题，分享给你们。

第一个经验是关于“不要盲目追求最新版客户端”。WinGet 客户端如果更新得太激进，有时会因为 manifest 结构变化导致某些老脚本失效。我自己就碰到过一次，某天升级完客户端后，之前一直正常的批量安装脚本突然开始报错。后来发现是新的客户端把某些字段的解析方式改了。所以如果你有一套跑得好好的自动化脚本，没必要天天折腾升级客户端，偶尔升级一次即可。反而软件清单winget source update可以勤跑一点，因为它只影响搜索和安装结果，不影响脚本结构。

第二个经验是“优先使用 MSI 包格式的软件”。WinGet 支持 msix、msi、exe、zip 等格式。从安装稳定性角度讲，msi 和 msix 格式的安装包通常比较规整，支持静默安装的程度也高。而 exe 格式要看厂商的心情，有些 exe 是 InstallShield，有些是 NSIS，有些是自解压脚本，静默参数各不相同。如果同一个软件在 WinGet 里有不同的包格式选择，尽量挑 msi 或 msix 那个。

第三个经验是用--scope参数来区分用户级和机器级安装。支持这个参数的软件，比如 Visual Studio Code，可以用--scope user装到用户目录，不需要管理员权限；用--scope machine则装到 Program Files，需要 UAC 提权。如果你经常在一个没有管理员权限的账户下开发，尽量用--scope user来安装，这样可以绕开很多权限问题。

第四个经验是出了问题先看日志。WinGet 的日志在：

%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

里面按日期存了 .log 文件。排查网络、依赖、安装参数问题时，打开最新的日志搜error或failed关键词，比你在网上瞎搜别人的报错文章管用得多。

最后一个小技巧：如果某个软件在 WinGet 里装完之后桌面没有快捷方式，不要急着以为安装失败了。因为有些静默安装模式的软件确实不会主动创建快捷方式。去开始菜单里搜一下软件名，或者在%ProgramData%\Microsoft\Windows\Start Menu\Programs目录看看有没有，没有再去“应用和功能”里确认软件本体是否存在。确认本体在，就说明装好了，快捷方式的事只是小事。

WinGet 的能耐远不止我这篇文章里写的这些，它还能配合 GitHub Actions 做持续集成、通过--force强制重装损坏软件、用--hash做安装包校验等。但核心思路你已经掌握了：它是一个命令行入口，帮你把“找软件、下软件、装软件、升级软件”这件事标准化、批量化。当你习惯了这种工作方式，再也不会想回到手动点安装向导的日子。