Delphi上架Microsoft Store：Windows SDK下载安装与配置全指南

1. 为什么要单独写一篇SDK下载安装：这是整个上架流程里最容易被看轻的环节

如果你搜过"Delphi Microsoft Store上架"，会发现网上教程大多集中在打包、签名、提交这几个环节，SDK安装基本一句话带过："去微软官网下载SDK装一下就好"。我第一次看到这种说法时也觉得挺简单，但真正动手才发现，这个"装一下就好"里藏着不少细节，足以让一个熟练的Delphi开发者在上面耗掉半天时间。

先说清楚一件事：Delphi开发Desktop应用和Microsoft Store上架之间，隔着一整套微软的现代工具链。传统Win32程序那一套（VCL编译出来的exe直接分发）在Store上完全行不通，Store要求的是MSIX打包格式、带签名证书的安装包、以及符合现代Windows应用模型的应用身份。这些能力不会凭空长在Delphi里，必须依赖微软提供的SDK和工具链去补齐。

这篇文章是我个人上架实战系列的第二篇，上一篇讲了账号注册和开发者中心的前置准备，这一篇聚焦在SDK下载安装这个"看起来无关紧要、实际决定成败"的环节。我会把整个SDK环境的来龙去脉、安装步骤、版本选型逻辑、以及我在实际安装中踩过的坑一次性讲清楚。不管你是第一次接触Store上架，还是已经打包过几个应用但被SDK环境整得头疼，这篇文章应该都能帮你省下不少摸索时间。

2. 正式动手前：搞清楚你和你电脑的当前状态

在点开任何下载链接之前，先确认三件事：操作系统版本、Delphi版本、以及目标编译架构。这三者共同决定了你该装什么版本的SDK、装完怎么配置。

2.1 操作系统版本检查：Win10还是Win11，Store的底层要求不同

Microsoft Store的现代化应用模型在不同系统上支持度不一样。Win10 1809之前的版本对MSIX打包应用的支持非常有限，需要额外的运行时组件；Win10 1809及以后、Win11则直接内置了完整的AppX/MSIX部署支持。

实际上微软官方对开发者提交Store应用的最低系统要求是Win10 1809，但考虑到开发环境的稳定性和调试工具的兼容性，我个人的建议是直接用Win11，或者至少把Win10系统更新到22H2。原因很简单：新版Windows SDK和打包工具链在某些旧版Win10上跑起来可能出现莫名其妙的问题，比如签名工具找不到系统组件、模拟器无法启动等，排查起来非常费时间。

检查方法不陌生：按Win+R，输入winver，回车，就能看到当前系统版本号。这一步30秒就能完成，但能避免后面好几种"灵异问题"。

2.2 Delphi版本确认：太老的版本基本不建议走Store路线

Delphi从10.3 Rio开始对Windows应用打包有了明显改进，10.4 Sydney和11.x Alexandria在Store支持方面更加成熟。到Delphi 12 Athens之后，IDE内置了对MSIX打包流程的整合，配置起来顺畅得多。

如果你的项目还停留在Delphi 10.2或更早，先别急着装SDK，先评估一下升级成本。不是说老版本完全不能上Store，而是你需要手工处理的兼容性适配工作会成倍增加，而且某些新版Windows SDK的头文件和老版本编译器之间会有冲突，编译阶段就会把你卡住。

这里多说一句，系列标题里提到的Delphi 13，也就是Delphi 13 Athens（这里指新版版本号体系下的对应版本），我实测下来对官方新版Windows SDK的兼容性是最好的，RAD Studio自带的MSIX工具链能直接调用External SDK的组件，省去了不少手工写脚本的功夫。

2.3 目标架构规划：x64、x86还是ARM64

这个决策看起来简单，实际影响着你装SDK时要勾选哪些组件。如果只想快速出一个能跑的包，x64就够；但如果你的应用需要兼顾老用户的Win10 x86系统，就得装x86的编译支持；如果要面向ARM64设备（比如Surface Pro X系列），那就需要额外安装ARM64构建工具，而这部分工具链的体积和配置复杂度都要高不少。

我自己的项目选型是主推x64，同时保留x86兼容包。原因有两层：一是当前Store平台对x64应用的分发权重明显更高，二是x86包可以覆盖一部分还在用老设备的用户。ARM64我暂时没上，因为开发调试成本高，受众又小，性价比不划算。

3. Windows SDK下载与安装：版本选择逻辑和完整操作记录

这一节是重头戏，也是网上教程最容易"语焉不详"的地方。我尽量把每一步的原理、选择和操作都讲透，你照着走就不会翻车。

3.1 版本选择：Windows SDK、Windows App SDK、MSIX工具链，一次分清

在微软的下载中心，你会看到好几个名字相近的SDK，它们的分工完全不同，别搞混：

• Windows SDK：这是最基础的系统级SDK，提供Windows API头文件、库文件、以及部分命令行工具（比如签名工具MakeCert、SignTool等）。凡是做Windows桌面开发都绕不开它，这是整个环境的地基。

• Windows App SDK：这是微软后来推出的"新一代应用开发SDK"，提供WinUI 3、DWriteCore、AppLifecycle等现代API能力。严格来说，纯Delphi VCL应用不太依赖它，但如果你要接Store的某些新特性（比如App通知、后台任务），未来很可能要用到。

• MSIX Packaging Tools：这是专门用来创建、编辑MSIX安装包的工具集，主要提供图形化界面，用来给已有应用重新打包成MSIX格式。Delphi IDE虽然有内置打包配置，但很多情况下还是需要靠这个工具做精细化的包配置。

• .NET SDK（部分场景需要）：不要奇怪，Delphi项目上Store为什么要装.NET SDK？因为MSIX打包工具的底层脚本有些是用C#写的，或者某些自动化流水线需要调用dotnet CLI去执行打包操作。如果只是手动图形化操作，这步可以跳过；但如果想搭自动化打包流程，建议一并装上。

实际开发中，大多数Delphi项目最终需要的是：Windows SDK（必须）+ MSIX Packaging Tools（强烈建议）+ Windows App SDK（可选，看需求）。

3.2 从微软官网正确获取Windows SDK安装器

Windows SDK的官方下载页面地址是微软的developer.microsoft.com，具体路径是"Windows SDK"下载页面。注意，搜索"Windows SDK下载"时，可能搜到大量第三方捆绑站，这些站点往往会在安装包里夹带私货或者提供过时版本，务必认准域名以microsoft.com或aka.ms开头，或者使用微软官方提供的Windows SDK存档页面。

打开官方下载页后，会看到一个"Download Windows SDK"按钮，点击后下载的是一个在线安装引导器，体积很小（几MB），运行后才会真正下载Components。这种在线安装器有好有坏：好处是你不需要自己手动筛选冗长的离线ISO，缺点是一次安装失败后整个流程要重来。个人建议下载离线ISO版本（页面下方通常会提供"Windows SDK ISO"或通过archive页面获取），离线包的好处显而易见：一次下载，多台机器可复用，安装时可离线安装，不用反复下载同一批组件。以Windows 11 SDK（版本号22000）为例，ISO文件大小约1GB左右，MB级别的在线安装器下载起来快，但实际安装过程还是会从微软服务器拉取内容。

我测试过多个长期支持版本后，推荐的选型是：

选择的原则很简单：不要追求最新，而是要"主流版本+足够兼容"。Windows 11 SDK (22621)是目前平衡性最好的版本，既能用上较新的API功能，又不会像预览版那样存在未知风险。

3.3 安装全程：哪些组件必须勾选、哪些可以放下

安装Windows SDK时，界面会列出多个可选组件，这里进行分组说明：

• 必须勾选：

  • "Windows SDK for Desktop Apps (x86/x64/ARM64)"：这是核心API头文件和库文件，不装这个，后面Delphi调用Windows API时就会缺少链接库。
  • "Windows SDK for Store Apps"：这个听起来像只给UWP用，但实际上MSIX打包格式的基础支持也依赖它，建议勾上。
  • ".NET Framework SDK"：部分工具链（特别是MSIX打包工具）需要对应的.NET Framework支持库，建议保持默认勾选。

• 建议勾选：

  • "Desktop App with WinUI 3"：如果你未来有向WinUI 3方向演进的打算，可以勾上。
  • "MSIX Packaging Tools"：如果在组件列表中看到这个选项，直接勾选。它是打包过程的重要帮手。

• 可以不勾选：

  • "Windows Performance Toolkit"、"Debugging Tools For Windows"：做通用桌面应用开发时用得少，体积又大，除非你后续要做性能分析，否则没必要装。
  • "Tablet PC SDK"：现在Windows平板生态基本融合进通用API了，不再需要单独装这个。

安装过程没有太多交互，就是等待进度条走完，但这里提个醒：安装期间不要开着Visual Studio或其他占用大量系统资源的IDE，否则可能出现文件占用导致的组件注册失败。这个坑我踩过，后面在避坑章节细说。

3.4 安装后立刻做的三件事（很多人忽略）

SDK装完不等于环境配好，我还记得第一次装完就兴冲冲去Delphi里配置环境，结果编译时各种找不到头文件。所以装完后请按下面步骤做一遍：

第一步：确认环境变量。打开控制面板 -> 系统 -> 高级系统设置 -> 环境变量，检查是否有名为WindowsSdkDir的环境变量，其值应该指向SDK安装路径（如C:\Program Files (x86)\Windows Kits\10\）。如果没有，手动添加，否则Delphi在查找SDK时会找不到默认路径。

第二步：确认Debuggers和SignTool路径。SDK里两个核心工具需要记住位置：

• SignTool.exe：默认在C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe
• MakeCert.exe或New-SelfSignedCertificate：用于生成自签名证书（开发阶段用） 这两个工具的路径后面打包配置时要用，建议提前抄到笔记里。

第三步：检查Delphi里的SDK已经自动识别。打开Delphi IDE -> Tools -> Options -> Deployment -> SDK Manager，正常情况下应该能看到系统自动检测到了刚安装的Windows SDK。如果没看到，点击"Add"手动添加SDK路径。Delphi 12和Delphi 13这几版对SDK的自动检测做得很好，但老版本可能需要手动配置。

4. Delphi环境里的SDK关联配置：让RAD Studio真正"用上"SDK

SDK装好了，但如果Delphi里没配置好，等于白装。这一节讲IDE层面的集成，我会先把推荐配置列出来，再解释为什么这么配。

4.1 SDK Manager里的6个关键配置项

按Win+R打开Delphi IDE后，进入Tools -> Options -> Deployment -> SDK Manager，你会看到一系列配置项。逐个说明：

4.2 手动添加SDK的完整路径

如果你的Delphi版本够老、没能自动识别SDK，需要手动添加。步骤并不复杂，但有一个地方很容易错：平台类型选错。比如你装的是x64编译支持，但Platform选择时误选了Win32，后面编译时会莫名报"无法链接系统库"。

手动添加路径时，注意几个关键点：

• SDK路径选到10这一级（即Windows Kits\10），不是bin，不是Lib，更不是具体的10.0.xxx版本目录。因为这一级目录结构包含bin/Include/Lib等完整子目录，Delphi是通过它来定位所有组件的。
• 点击"Refresh"按钮，让IDE重新扫描SDK里的头文件和库文件。这一步会扫出Compilers、Tools、RTTI等组件列表，扫描需要几秒钟，不要中途关闭，否则下次打开又得重来。
• 如果界面上出现红色叉号或警告图标，说明某个组件不匹配，鼠标悬停上去看详细信息，通常是某个库文件缺失，回去SDK安装界面补勾对应组件即可。

4.3 编译器版本与SDK版本的兼容性匹配

Delphi各版本的编译器对Windows SDK的兼容性不完全相同，特别是老版本Delphi编译时可能会报头文件语法错误（Windows SDK的新头文件使用了某些较新的C语言语法，老编译器解析不了）。这种情况下可以试试以下方法：

• 使用较旧版本的Windows SDK（如Windows 10 SDK 19041）与Delphi 10.3/10.4配合使用。
• 或者在IDE里通过搜索路径过滤掉新版头文件的某些目录，显式指定老版本头文件优先。

但这个坑只影响老版本用户，用Delphi 12/13配合新版SDK基本不会遇到。这个问题的本质，是现代SDK的头文件语法越来越"现代"，老编译器不认，属于典型的工具链代差问题。

4.4 版本切换的常见场景

有时候你会遇到这种情况：项目要求必须用某个SDK版本编译，而你机器上装了多个Windows SDK版本。此时，在SDK Manager里创建多个SDK配置（一个针对SDK 22621，一个针对SDK 19041），在项目属性的"SDK"下拉框中随时切换即可。不过要注意，切换SDK后建议做一次Project -> Clean，再全量Rebuild，因为有些临时文件可能还引用着旧SDK的路径。

5. MSIX打包工具补全：光有SDK还差临门一脚

SDK装好后，讲一个很关键的补全工具MSIX Packaging Tools。如果只装Windows SDK，打包阶段会缺一个图形化工具，导致你不得不写一堆PowerShell命令来处理MSIX包。写脚本不是不行，但调试起来效率低，尤其对于不熟悉MSIX包结构的Delphi开发者来说，有个图形化工具辅助，出错会少很多。

5.1 安装MSIX Packaging Tools的两种方式

第一种方式：从Microsoft Store里搜"MSIX Packaging Tool"直接安装，简单粗暴，但这个工具是Store应用形式，有自己的更新节奏，有时候功能版本会落后。这里也回应一下系列标题里的"Microsoft Store SDK"——很多人会把被Store载体和Store上架工具链混淆，实际上Store应用内同样可以安装这类开发辅助工具，虽然这些工具的定位和功能是开发者用的，但它们以Store应用分发的形式存在，好处是更新相对自动。

第二种方式（推荐）：从微软官方GitHub Release页面下载MSIX Packaging Tools的安装包，好处是可以指定版本，方便和Windows SDK保持一致。下载后解压得到.appx或.msix文件，右键选择"Add package"即可安装。

5.2 用MSIX Packaging Tool把已有Delphi程序包成MSIX

从工具的任务界面看，它做得比较友好，主要功能就两大块：一是"Create app package from installed apps"（从已安装应用创建包），二是"Create app package from existing installer"（从已有安装程序创建包）。

针对Delphi项目，我建议用第二种，因为我们已经有编译好的应用文件（exe加dll），不需要先安装到系统里再捕获。操作流程简述：

1. 打开MSIX Packaging Tool，选择"Create MSIX package from existing installation files"。
2. 指定Delphi项目的Release输出目录，里面至少要有主exe文件和所有运行时dll。
3. 在Package Information步骤填写"Display name"、"Publisher display name"等元数据。这里的"Publisher"必须和你后面用于签名的证书中的主体名称完全一致，否则安装时会报"无法验证发布者"错误。
4. 选择安装目标架构，这里注意选x64（或与你的Delphi编译目标一致）。
5. 点击Create，工具会扫描目录里的所有文件，生成.msix包。

这个环节里，最容易出问题的就是Publisher不匹配。每次在这个环节卡住，都是因为没有提前把证书的Subject Name和使用信息统一。

5.3 为什么要用MSIX而不是直接扔一个exe给用户

这个问题可能有人心里会嘀咕：既然Delphi程序可以直接运行exe，为什么非要费劲打包成MSIX再上Store？因为Store平台本身就是围绕MSIX这套应用交付体系设计的：

• 自动更新能力：Store客户端可以自动拉取新版本MSIX包并静默替换，用户不需要重新下载安装器。
• 干净卸载：MSIX包里的应用安装时会创建完整清单，卸载时可以从系统里清除所有相关文件，不像传统exe安装程序那样容易留下一堆垃圾文件。
• 沙盒化运行：MSIX应用有权限控制和虚拟化注册表，大大降低了应用对系统的侵入性。
• Store审核要求：提交到Store的应用必须采用MSIX或AppX格式，这是硬性规定。

对于Delphi这类传统桌面技术栈，MSIX相当于一套"新瓶装旧酒"的方案，你必须接受这套包装逻辑才能搭上Store的分发快车。

6. 证书、签名工具与开发者模式：容易忽略的最后一块拼图

SDK和打包工具都就位后，还有一类"隐性组件"容易被忽略——证书与签名。Store上架要求所有MSIX包必须使用受信任的证书签名，开发阶段则可以用自签名证书过渡。

6.1 用New-SelfSignedCertificate生成开发用自签名证书

命令我贴出来，这是我在开发环境里验证过可用的：

# 以管理员身份运行PowerShell New-SelfSignedCertificate -Type Custom ` -Subject "CN=YourCompanyName" ` -KeyUsage DigitalSignature ` -FriendlyName "YourCompanyName Dev Cert" ` -CertStoreLocation "Cert:\CurrentUser\My" ` -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}Subject Key Identifier")

执行后，系统会返回一个带Thumbprint的证书对象，记下这个Thumbprint值，后续签名时要用。注意，这个证书默认放在"当前用户"的证书库里，签名时要指定对应的证书存储位置。

6.2 用SignTool对MSIX包签名

生成证书后，用SignTool签名，命令如下：

signtool sign ` /fd SHA256 ` /a ` /d "YourAppName" ` /n "YourCompanyName" ` /f C:\path\to\your.pfx ` /p YourPassword ` "C:\path\to\your.msix"

参数解释：

• /fd SHA256：指定文件摘要算法，微软强制要求使用SHA256。
• /a：自动从证书库中查找匹配证书（前提是证书已导入到当前用户的证书库）。
• /n：按证书主题名称匹配，填上面生成证书时Subject里的"YourCompanyName"。
• /f：如果有专门的.pfx文件，可以直接指定文件路径。
• /p：pfx证书的密码。

签名后可运行以下命令验证签名是否有效：

signtool verify /pa /v "C:\path\to\your.msix"

看到输出中包含"Signatures verified"字样就算通过。当年我在这上面踩过一个坑，稍后专门说。

6.3 开发者模式的开启：本地安装MSIX的前提条件

MSIX包在正式发布前，需要在本地测试安装，但Windows默认阻止未签名或自签名的MSIX包安装。这时就有两种途径：

1. 开启开发者模式：设置 -> 隐私和安全性 -> 开发者选项 -> 打开"开发人员模式"。开启后，从本地安装自签名的MSIX包时，系统不会弹"应用包不受信任"的拦截提示。
2. 安装临时的信任链：直接把自签名证书导入到"受信任的人"证书存储区。做法是双击.msix包 -> 在安装界面选择"安装"前，先从证书管理器中把.pfx导入到"本地计算机 -> 受信任的人"目录，再安装。

两者选一个都行，但建议两件事都做。因为哪怕开发者模式打开了，MSIX安装器在某些情况下仍然会验证证书链，证书不受信任时同样被拦。开发者模式能解决一部分权限问题，但它不替代证书信任链的建立。

7. 实操避坑记录：我在SDK安装过程中踩过的5个坑

这一节是"压舱石"内容，回顾整个SDK下载安装到环境配置过程中最典型的5个坑，每一个都是实际发生的，不是凭空想象。按从高到低的影响程度排列。

7.1 安装Windows SDK时被"文件占用"卡住，最终重建环境才解决

这是最让人崩溃的坑。当时我装着Visual Studio 2022，同时Delphi IDE也开着，直接运行SDK在线安装器。结果安装到某个组件时，进度条不动了，弹出的错误提示大致意思是"无法安装：某个文件正在被占用"。

排查过程：先关闭Delphi IDE和VS，再重新安装，还是失败。后来才发现，问题不在于Delphi或VS本身，而是后台有一个Windows Update进程一直在占用系统更新组件，SDK安装器要修改的系统文件恰好被它锁住。最终解决方法是：重启电脑，开启飞行模式断开网络，暂停Windows Update服务，再重新运行安装器，这次顺利通过了。

经验总结：安装Windows SDK前，关掉VS、关掉Delphi、关掉其他用MSBuild进程的软件；有条件的话断网安装。安装完成后重启一次系统，再打开IDE，让所有系统环境变量刷新。

7.2 Delphi IDE无法识别已安装的SDK

第二个坑是SDK明明装好了，但SDK Manager里看不到。后来发现原因：SDK安装在默认路径C:\Program Files (x86)\Windows Kits\10下，但Delphi是以32位模式运行（RAD Studio的IDE本身是32位程序），访问Program Files (x86)没有问题，但问题是SDK Manager默认扫描的时候只认了特定路径下的特定目录结构，如果SDK的安装路径被自定义过，或者版本目录结构缺失（比如没有bin、Lib等子目录），IDE就会找不到。

解决方式是：在SDK Manager里手动添加，把SDK路径指到C:\Program Files (x86)\Windows Kits\10，再点"Refresh"刷新。有一个细节：如果安装SDK时只勾选了"部分组件"，比如只选了Debuggers没选Lib目录，那么IDE扫描的时候会因为Lib目录缺失，无法建立完整的SDK配置。所以再一次强调那件事：Desktop Apps SDK组件必须勾上。

7.3 签名时报"找不到证书文件"，结果问题出在导入方式

用SignTool签名时，我传入了一个.pfx文件路径，结果一直提示"找不到证书文件"。排查后发现，签名工具的各种调用方式中，/f参数要求的是导入到证书库后再用，或者需要先把.pfx导入到"当前用户的证书库"中。

正确操作是：双击.pfx导入 -> 选择"本地用户" -> 然后把证书放在"个人" -> "证书"目录下，导入后签名时用/a自动查找（或/s my指定当前用户个人存储区）。以后再签名就不要用/f指向文件了，直接/a和/n配合最省事。

7.4 MSIX包安装时报"发布者无法验证"

这个问题和证书签名是一环扣一环的：MSIX包里的Publisher元数据（我记得是这个，也建议你核对下）必须和签名证书中Subject的CN完全匹配。举个例子：如果打包时填的Publisher是"CN=Example Company"，而证书里写的Subject是"CN=ExampleCompany"，有一个空格差异或者大小写差异，安装时就会出现无法验证发布者的提示。

解决办法不是去MSIX包里改Publisher字段，而是直接改证书或重新打包。开发阶段最简单的方法是：修改打包时输入的Publisher name，让它和你签名的证书的CN完全一致。如果项目对两者的一致性没有把握，可以打开MSIX包里的AppxManifest.xml检查Publisher字段，再和证书信息对比一下。

7.5 Store提交后审核失败：SDK版本配置和打包架构不一致

这个是最"隐性"的坑：打好的MSIX包在本地测试安装完全正常，但提交到Microsoft Store合作伙伴中心后，认证流程报错，提示"Package architecture mismatch"或"SDK version not supported"。

调查发现原因：本地编译时Delphi项目的目标平台是Win32（x86），打包工具里选了x64架构。两边的架构不对齐，MSIX包的元数据里记录的是x64，但实际exe文件是x86，Store的认证系统检测到这种不一致后直接打回。

这个坑给我们的教训是：在Delphi里配置项目时，目标平台是什么，打包时就要选对应的架构。如果打算提交x64的包，Delphi项目属性里的Target Platform一定要是x64，并确保Release配置下重新全量编译；如果同时想覆盖x86用户，那就单独打包x86架构的MSIX，一次提交多个包架构在Store平台上是允许的，不要试图在一个包里混两种架构。

8. 开发机配置核对清单、SDK相关工具链映射与版本关联参考

把前面几节的内容整合成一份可以直接照做的核对清单和一份我常用的SDK版本与工具链关联参考表，方便后续其他项目复用。

8.1 环境就绪自查清单（照做一遍，10分钟完成）

• [ ] 系统版本：Windows 10 22H2或Windows 11（winver检查）
• [ ] Delphi版本：10.3+，推荐Delphi 12/13
• [ ] Windows SDK：已安装，版本22621或22000，路径默认
• [ ] 环境变量已设置：WindowsSdkDir指向SDK根目录
• [ ] MSIX Packaging Tools已安装
• [ ] 开发者模式：开启（设置 -> 隐私和安全性 -> 开发者选项）
• [ ] 自签名证书已生成并导入到"当前用户"证书库
• [ ] SignTool可正常运行（测试签名一个临时文件，输出"Done Adding Additional Store"）
• [ ] Delphi SDK Manager已识别SDK，平台与架构匹配项目需求
• [ ] 可以编译出一个Release版本的exe，并确认输出目录中无缺失DLL（用Dependency Walker或Process Explorer检查）

8.2 常用工具版本与适用场景映射

8.3 SDK环境跑通后的一个最小验证

等所有工具链都就位，建议做一个标准验证：用MSIX Packaging Tools把Delphi自带的一个示例项目（比如C:\Program Files (x86)\Embarcadero\Studio\23.0\Samples\Object Pascal\Database\FireDAC\TFDQuery\Project1.exe，具体名字不重要，核心逻辑是编译一个最小可运行程序）打包成MSIX，再在本地安装运行。如果这个流程走通了，说明从SDK到打包再到签名这一整条链路没有断点，接下来拿真正的主程序练手就心里有底了。

验证时注意：示例项目最好是用静态运行时编译（Project Options -> Runtime Packages -> Link with runtime packages，去掉勾选），这样生成的exe不依赖Delphi的运行时bpl文件，打包出来体积小，也便于排查依赖问题。

9. 从SDK安装到第一包成功：一个较陡但清晰的上坡路

SDK下载安装这件事，放在整个Microsoft Store上架流程里看，它没有打包签名那么"创造性"，也不像提交审核那样充满不确定性，但它是整条链路的起点。地基没打好，后面每一步都会受影响：可能是编译时找不到库文件，可能是打包时架构不对，可能是签名时证书不匹配，更可能是提交审核时才暴露出来的底层环境问题。

这一篇我把从版本选型、安装组件勾选、Delphi环境关联配置、MSIX打包工具补全、证书生成签名，到开发环境验证的整个链路完整走了一遍。受篇幅限制，有些部分（比如Store合作伙伴中心的详细配置、应用提交的人工审核流程）没展开，这些会在系列的后续文章中逐个讲。

分享一点个人体会：这套工具链首次配置确实繁琐，因为它把Delphi这一套老牌的、习惯"双击运行"的开发思维，强行接入了微软现代应用生的分发体系。两者之间存在理念差异很正常，但一旦理解了SDK和工具链各自的职责边界，再回首看整个流程，你会觉得其实每一样东西都有它存在的意义。SDK提供系统能力，打包工具负责封装，证书负责信任和身份，四者串联起来，才支撑起一个能被Store接纳的现代Windows应用形态。

最后再给一个扩展思路：如果后面你的项目要接Store平台提供的云签名、自动更新、甚至推送通知等能力，那Windows App SDK的安装就不是可选项了，建议提前熟悉起来。从我的实践看，先把基础SDK环境打磨稳定，再逐步引入平台特性，这条路比一开始就想着一次把所有新技术都接上要稳妥得多。