企业官网建设流程全解析

1. 先搞明白：你说的"注册"，到底是哪一种

上周有个同事扔过来一个压缩包，里面躺着三个 dll 和一句"帮我注册一下"。我打开一看：第一个是十多年前某套老系统留下的 COM 组件，第二个是 .NET 编译出来的业务库，第三个其实只是某个服务的插件，靠配置文件加载，压根不需要碰注册表。这三个东西命运完全不同，能直接"注册"的只有第一个。这几乎是所有人第一次接触 dll 服务注册流程时的共同困境——把几个名字相似、机理完全不同的动作，混成了一个词。

真正把这件事讲清楚，得先从"注册"这两个字开始拆。因为你在搜索引擎里看到的 regsvr32、regasm、sc create、installutil，它们解决的不是同一个问题，甚至操作的对象都不是同一类文件。搞混了，就会出现那种"命令跑完了、没报错、但程序还是说找不到组件"的诡异局面。

1.1 三种完全不同的"注册"

日常语境下说的"注册"，至少对应下面三件互不相干的事情，每一件的本质、工具和产物都不一样。

第一件是COM 组件注册。这类 dll 遵循组件对象模型规范，导出了DllRegisterServer和DllUnregisterServer两个函数。当你执行regsvr32 xxx.dll，操作系统做的事情其实非常朴素：把这个 dllLoadLibrary进来，找到DllRegisterServer这个导出函数，然后调用它。至于往注册表里写什么键值、写几个 CLSID，全是 dll 作者在那段函数里自己写代码决定的，regsvr32 只是个"加载器 + 调用器"。理解了这一点，很多怪现象就顺了：为什么有的 dll 用 regsvr32 注册会报"找不到入口点"——因为它根本就没导出那个函数。

第二件是托管程序集注册。.NET 编译出来的 dll，默认情况下就是一个普通的 PE 文件，没有DllRegisterServer这种原生导出。它的类型信息全部藏在程序集元数据里。所以要用RegAsm.exe去读元数据，然后由 RegAsm 自己生成对应的注册表项。这也是为什么很多人拿 regsvr32 去注册 .NET dll，必然吃一个"找不到 DllRegisterServer 入口点"的报错。

第三件是Windows 服务注册。这里的"服务"是 SCM（Service Control Manager，服务控制管理器）意义上的服务，是操作系统层面的一个后台进程托管机制。注册的动作本质上是往 SCM 的数据库里加一条记录，告诉系统："有这么个 exe，它的启动方式是这样，登录账号是那个，开机能自启。"注意，这条记录里登记的是exe 的路径，不是 dll。dll 在这里只是被 exe 依赖的库文件，它本身不需要"注册"，只需要能被找到。

把这三件事分开之后，你会发现所谓的"dll 服务注册流程"，实际落地的时候通常是两段拼起来的：先用 regsvr32 或 regasm 把组件挂到注册表上，再用 sc create 把承载它的可执行文件登记成服务。

1.2 注册过后，系统里多了什么

要判断一次注册是否真的成功，你得知道成功的标志长什么样。最直接的办法就是去注册表里翻。COM 组件的注册信息，绝大多数落在下面这几个位置：

这里有两个特别容易让人栽跟头的地方。第一个是Wow6432Node。在 64 位系统上，32 位组件的注册信息会被重定向到HKLM\SOFTWARE\Classes\Wow6432Node\CLSID\...下面，而 64 位组件的注册信息在HKLM\SOFTWARE\Classes\CLSID\...。它们看起来像是同一个目录，其实是两套并行的注册表空间。你用 32 位的 regsvr32 注册完，去 64 位的位置翻，当然什么都找不到。

第二个是ThreadingModel。这个值决定了组件被加载到哪种 COM 套间里。Apartment是最常见的 STA 单线程套间，Both表示可以进 STA 也可以进 MTA，Free是 MTA，Neutral用于无套间场景。这不是可选项，写错了组件在某些宿主进程里会直接加载失败或者出现诡异的阻塞。如果你自己写 DllRegisterServer，ThreadingModel必须显式写进去，不写的话默认行为在旧系统上可能碰巧能用，在新系统上就不一定了。

2. 注册前的准备：位数、权限、依赖三件事

我见过太多人一上来就敲命令，报错了再回来找原因，结果绕了一大圈发现是位数不对。其实注册这件事的前置检查就三条：位数、权限、依赖。这三条过一遍，能省掉后面八成的排错时间。

2.1 位数对不上，后面全是白费

判断 dll 是 32 位还是 64 位，最靠谱的工具是 Visual Studio 自带的dumpbin，或者在开发者命令提示符里直接跑：

dumpbin /headers C:\path\to\your.dll | findstr machine

输出里会出现x86（32 位）、x64（64 位）或者ARM64。如果你手头没有 VS，也可以装一个轻量的 PE 头查看工具，很多整理包管理器里都有 GUI 版本，拖进去就能看。

判断出来之后，注册的时候就必须用对应位数的 regsvr32。这一点是硬性的：

这张表第一次看会很反直觉：64 位系统里，System32目录放的其实是64 位系统文件，而SysWOW64目录放的才是32 位的文件。这个命名是历史包袱，微软自己也承认是个糟糕的命名，但它已经没法改了。所以当你要注册一个 32 位组件时，必须显式写全路径C:\Windows\SysWOW64\regsvr32.exe，而不是直接在命令行敲个regsvr32——后者从 64 位的命令行解析出来的通常是 64 位那一个。

顺带说一个实际经验：如果你在 64 位系统上用错了 regsvr32，报的错往往不是"位数不匹配"这么友好，而是0x8007007E 找不到指定的模块或者干脆无提示失败。因为 64 位进程去加载 32 位 dll 时，LoadLibrary阶段就挂了，连接下来要执行的 DllRegisterServer 都走不到。

2.2 权限与注册表写入位置

往HKLM下面写东西，必须有管理员权限。所以正常的注册流程是：以管理员身份打开命令提示符，再执行 regsvr32。如果你只是普通权限双击运行，组件自己的 DllRegisterServer 里那段写注册表的代码会拿到ERROR_ACCESS_DENIED，最终 regsvr32 弹出来的就是个笼统的失败对话框。

但这里有个非常隐蔽的坑，值得单独拎出来说。提权之后，你的用户上下文变了。假设你以管理员 A 登录，然后提权执行注册，这时候进程的 HKCU 指向的是管理员 A 的用户配置单元，而不是当前交互登录会话的那个用户。如果某个组件的 DllRegisterServer 里恰好写的是HKCU\Software\Classes\CLSID\...（这种情况在"单用户免提权注册"的设计里是存在的），那么注册信息就写进了 A 的配置单元。你以普通用户 B 身份跑程序，B 的 HKCU 里什么都没有，程序就会报"类未注册"。

处理这类问题的办法是明确区分两种注册模式：

• 机器级注册（per-machine）：写HKLM，需要管理员权限，全机器所有用户可见。
• 用户级注册（per-user）：写HKCU，不需要管理员权限，只对当前用户可见。

注册的时候用哪个模式，应该由组件的部署场景决定，而不是随手敲。对于安装在Program Files下面的正式组件，老老实实走机器级；对于绿色部署、放在用户目录下的组件，走用户级反而更干净。

2.3 依赖检查：别等到报错才想起来

一个 dll 从来不是孤立存在的。它自己会依赖 VC 运行库、.NET 运行时、系统 API 集、以及同目录或系统目录下的其他 dll。注册的时候 regsvr32 会把这个 dll 加载进内存，只要有一条依赖链断了，加载就会失败。

查依赖链有几个手段。老牌的 Dependency Walker 在新系统上经常误报，因为它不认识 API Set 的虚拟 dll（比如api-ms-win-crt-*.dll），现在更推荐用Dependencies（一个开源的重写版本），它能正确识别 API Set 和延迟加载。

如果你想看最原始的导入表，用 dumpbin：

dumpbin /dependents C:\path\to\your.dll

但真正最好用的还是Process Monitor。它能看到注册那一刻运行时实际去哪些路径找了哪些文件、哪些找失败了。过滤条件设成：

Process Name is regsvr32.exe Operation is CreateFile Result is NAME NOT FOUND

跑一遍注册，ProcMon 里列出来的每一个NAME NOT FOUND，都是运行时尝试加载但没找到的文件。这里面有的是正常的探测行为（系统会按顺序试多个路径），有的就是真实缺失的依赖。判断方法很简单：把路径拿去资源管理器里确认一下，文件确实不存在，而 dll 名字又是你程序相关的，那就是缺了。

注意：不要图省事去网上随便下载所谓的 dll 修复工具或者单独的 dll 文件往系统目录里塞。这个做法有三个致命问题：一是来路不明的二进制文件本身就是安全风险；二是版本不匹配会导致更隐蔽的崩溃；三是往System32里塞文件会污染系统目录，后面出问题极难定位。正确的做法是找到这个 dll 的官方来源——通常是某个运行时可再发行包，装上对应的安装包，让它自己完成部署。

3. COM 组件注册实操：regsvr32 与 regasm

前置检查做完，就可以进入真正的注册环节了。这一段我把原生 COM 和托管程序集分开讲，因为它们的工具链完全不重叠。

3.1 regsvr32 的正确用法

regsvr32 的参数不多，但每个都有明确用途，值得记牢：

:: 静默注册，成功与否都不弹窗 regsvr32 /s C:\path\to\your.dll :: 卸载注册 regsvr32 /u /s C:\path\to\your.dll :: 带参数调用 DllInstall（有些组件靠这个区分安装/卸载场景） regsvr32 /i C:\path\to\your.dll :: 只调用 DllInstall，不调用 DllRegisterServer regsvr32 /n /i:user C:\path\to\your.dll

/s这个参数在批量部署脚本里几乎是必加的，因为默认情况下 regsvr32 会弹一个模态对话框，脚本里没人去点它，进程就会一直挂在那里。加了/s之后，成败只能靠返回码判断。这里有个细节：regsvr32 的返回码并不可靠，它在某些失败场景下依然返回 0。所以真正严谨的部署脚本，注册完之后一定还要做一次验证（见 3.3 节）。

/n和/i的组合是给那些"同时支持机器级和用户级注册"的组件准备的。/i:user会把user这个字符串作为参数传给 dll 的DllInstall函数，dll 内部根据这个参数决定写 HKCU 还是 HKLM。这是微软官方给出的用户级注册约定。

还有一个容易忽略的点：注册路径里不要有中文和非 ASCII 字符，至少在排查阶段尽量避免。虽然现代 Windows 对 Unicode 路径支持已经很好了，但一些老组件的内部实现用的是 ANSI 版本的 API，遇到非 ASCII 路径会静默失败。我习惯把要注册的 dll 先复制到一个纯英文短路径下，比如C:\temp\reg\，注册验证通过之后再移到最终位置并重新注册一次。

3.2 .NET 程序集：regasm 才是正路

托管程序集要靠RegAsm.exe。这里同样有位数问题：32 位的用Framework目录下的，64 位的用Framework64目录下的。

:: 注册为 COM 可见组件，同时导出类型库 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe ^ C:\path\to\MyLib.dll /codebase /tlb:MyLib.tlb /verbose :: 卸载 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe /u C:\path\to\MyLib.dll

/codebase这个参数值得单独讲。不加它，RegAsm 只在注册表里写程序集名称和版本，运行时靠"探测"去找 dll——它会沿着 exe 所在目录、AppDomain的私有路径、GAC 一层层找。加上了它，注册表里会多写一个CodeBase值，直接给出 dll 的绝对路径，运行时优先按这个路径加载。

问题在于，CodeBase是一把双刃剑。它让加载变得确定，但也把 dll 的位置锁死了——你后来把 dll 挪了位置，注册信息里还是老路径，程序就会报加载失败。而且微软明确建议：强名称程序集应该装进 GAC，而不是依赖 CodeBase。所以我的实践是：

• dll 有强名称、要发布给多个程序共用：gacutil /i MyLib.dll装 GAC，RegAsm 时不加/codebase。
• dll 是私有组件、只给某一个程序用：把 dll 放在 exe 同目录，RegAsm 不加/codebase，靠探测路径找到。
• 实在找不到、又不想动 GAC：才用/codebase，并且记住"dll 不能挪位置"这条约束。

/tlb是导出类型库文件，主要给脚本宿主、老式 IDE、跨进程编组用。如果调用方是 C# 或者 C++，通常用不上；如果要用 VBScript、PowerShell 早期版本、或者通过 COM 跨进程调用，那就必须导出并注册类型库，否则会拿到0x8002801D 库未注册。

3.3 验证注册是否成功

注册命令跑完，别急着庆祝。三种验证方式，从粗到细：

第一种，翻注册表。如果你知道组件的 CLSID，直接查：

reg query "HKLM\SOFTWARE\Classes\CLSID\{你的-GUID}" /s

输出里应该能看到InprocServer32分支、ThreadingModel值、以及指向的 dll 路径。注意路径必须是完整绝对路径，而且要和你实际部署的位置一致。如果这里指向了一个旧路径，说明注册信息是历史残留，需要先/u卸载再重新注册。

第二种，实际实例化一次。这是最有说服力的验证：

$obj = New-Object -ComObject "YourApp.YourClass.1" $obj | Get-Member

能创建出来，说明 CLSID、ProgID、InprocServer32 这一整条链路是通的。报0x80040154 类未注册说明注册信息没写进去，或者写错了 hive/位数；报0x8007007E说明注册信息对了，但加载 dll 的时候依赖断了。

第三种，用可视化工具看。OleView.NET 这类工具可以把 CLSID、接口、类型库都列出来，对着看很直观。老牌的 OleView 在新系统上已经不太能用了，找 OLE/COM Object Viewer 的 .NET 重制版更稳。

4. 服务注册实操：sc create 到 sc start 的完整链路

组件注册完之后，接下来这一步是把承载它的 exe 登记成 Windows 服务。这一步的操作对象是 exe，不是 dll，记住这一点能省掉很多困惑。

4.1 sc create 参数逐个拆

基础命令长这样：

sc create MyServiceName ^ binPath= "C:\app\MyService.exe" ^ DisplayName= "我的业务服务" ^ start= auto ^ obj= "NT AUTHORITY\LocalService" ^ password= ""

这里有一个堪称"经典中的经典"的坑：等号后面必须有一个空格。binPath=是对的，binPath =也对，但binPath="..."是错的，sc 会把整个东西当成参数名解析，然后抱怨"参数不正确"或者创建一个 binPath 为空的服务。这个设计源于 sc 的参数解析器沿用了老式命令行工具的约定，非常反直觉，但必须遵守。

第二个坑是路径里的空格。如果 exe 路径包含空格，比如在Program Files下面，光加引号还不够，因为外层已经有一层引号了，需要用反斜杠转义内层引号：

sc create MyServiceName binPath= "\"C:\Program Files\My App\svc.exe\" --config \"C:\Program Files\My App\conf.xml\""

如果参数再复杂一点，建议先去写一个.bat或者.cmd启动脚本，把复杂参数都放进脚本里，binPath只指向那个 bat，能避开大量的转义地狱。这也是很多实际项目的做法。

几个关键参数的含义整理如下：

创建完之后，启动和查询：

sc start MyServiceName sc query MyServiceName sc qc MyServiceName :: 查看配置详情 sc config MyServiceName start= demand sc delete MyServiceName

sc delete之后，服务在服务管理器里不会立刻消失，要刷新（或者重启服务管理控制台）才会从列表里去掉。这不是删除失败，只是 UI 缓存。

4.2 PowerShell 与 .NET 服务安装器

如果你更习惯 PowerShell，等价的操作是New-Service：

New-Service -Name "MyServiceName" ` -BinaryPathName "C:\app\MyService.exe" ` -DisplayName "我的业务服务" ` -StartupType Automatic

它的好处是参数不用写那个诡异的空格，写起来干净得多。但灵活性不如 sc——比如指定服务账号密码、设置依赖关系，还是得回到sc config去补。我的习惯是：创建用 PowerShell，精细调整用 sc。

还有一条路是 .NET 的ServiceInstaller组件配合installutil.exe：

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe C:\app\MyService.exe

这种方式需要你的服务项目里显式添加ServiceProcessInstaller和ServiceInstaller，并且把服务名、显示名、启动类型都写在代码或者设计器里。它的优势是可以跟着服务程序一起版本管理，部署的时候一条命令搞定；劣势是卸载的时候同样要跑InstallUtil /u，如果这一步漏了，残留的服务项在重启后会一直报"找不到可执行文件"。

4.3 服务账号怎么选

服务以什么身份跑，安全性和便利性的平衡点差别很大。

LocalSystem是权限最高的本地账号，几乎可以对系统做任何事，网络身份是计算机账号。图省事的时候很多人直接用这个，但它的权限远远超出一个业务进程需要的范围。一旦服务被利用，攻击面是整台机器。

LocalService权限最小，只有本地受限权限，网络上是匿名身份。适合不需要访问网络资源的本地后台任务。

NetworkService介于两者之间，网络上是计算机账号身份，本地权限也比较受限。

自定义域账号在需要访问域内资源（共享目录、数据库的 Windows 认证、其他服务）的时候用。这时候密码管理是个问题——服务账号密码改了，所有相关服务都要跟着改，忘了哪个就是一堆启动失败。生产环境里更推荐用组托管服务账号（gMSA），密码由域控自动轮换，不用人工维护。

选择的时候有个简单原则：从权限最低的那个开始试，跑不起来再往上加。而不是一上来就给 LocalSystem，出了问题再往后缩。

4.4 注册成功但服务起不来，问题出在哪

这是最高频的一种求助场景。"服务列表里已经有了，但启动就报错 1053 或者 1067"。这几个错误码背后对应的问题方向完全不同：

错误 1053（服务没有及时响应启动或控制请求），通常意味着服务进程启动了，但没在规定时间内（默认 30 秒，实际是 SCM 等待 OnStart 返回）向 SCM 报告自己已经就绪。常见原因有三个：一是服务代码里的OnStart里做了耗时操作，比如同步拉取大量数据、等待网络超时；二是服务的入口点压根不是有效的服务宿主程序，比如把一个普通的控制台 exe 强行注册成服务，它跑起来打印几行字就退出了，SCM 从来看不到状态上报；三是依赖的服务没启动，导致自己的初始化卡住。

**错误 1067（进程意外终止）**这个更直白，进程跑起来然后崩了。九成情况下是配置缺失、依赖文件找不到、端口被占用。这时候去看 Windows 事件查看器，路径是"Windows 日志 → 系统"，来源筛选Service Control Manager，看事件 ID：

**错误 5（拒绝访问）**通常在sc start阶段出现，原因是服务的运行账号对 exe 文件或者工作目录没有读/执行权限。表现是"注册好了，一启动就拒绝访问"。检查方法很直接：把 exe 所在目录的权限列出来，看看服务账号有没有读和执行权限。默认情况下LocalService和NetworkService对用户目录下的文件是没有访问权限的，服务放在C:\Users\xxx\下面必然出问题。

5. 常见报错与排查速查

前面几节讲的是"怎么让它跑起来"，这一节讲"跑不起来怎么救"。我把这些年攒下来的报错表和排查顺序整理一下，遇到问题直接查表能省不少时间。

5.1 高频错误码对照表

0x8007007E和0x80040154是最容易混淆的一对。区分它们的办法很简单：0x80040154说明系统根本没找到注册信息，0x8007007E说明注册信息找到了，但按注册信息里的路径去加载 dll 的时候失败了。所以如果报 7E，你应该去查注册表里那个 InprocServer32 的路径对不对、依赖全不全；如果报 154，先去确认注册表项到底写没写进去、写在哪个 hive、哪个位数分支下。

5.2 排查工具链与推荐顺序

我个人的排查顺序是这样的，从便宜到贵：

第一步，看返回码和事件日志。命令返回码、事件查看器里的 Service Control Manager 日志、注册表里对应的键值，这些是零成本的。大量问题在这一步就能定位。

第二步，确认位数和路径。用 dumpbin 确认 dll 位数，用资源管理器确认路径存在，用reg query确认注册表项内容。这一步能解决"注册表写进去了但程序找不到"这一类问题。

第三步，上 Process Monitor。前面两步都没结论的时候，ProcMon 是唯一能告诉你"运行时到底发生了什么"的工具。过滤Process Name和Result is NAME NOT FOUND，跑一次完整的注册或启动过程，看加载失败了哪些文件。

第四步，看导入表和依赖树。用 Dependencies 工具打开 dll，看整个依赖图里哪些节点标红。注意对 API Set 的误报要忽略。

第五步，上事件日志的应用程序日志。如果是 .NET 服务，这里会有托管异常堆栈；如果是原生程序崩溃，可能会有 WER 记录。

5.3 几个反复踩到的坑

坑一：卸载不干净导致的"幽灵注册"。一个组件注册了两次，指向两个不同的 dll 路径，程序加载到的是旧的那个。这种情况在测试机上升级版本之后特别常见。处理办法是每次注册之前先/u一次，不管上次有没有注册过。卸载失败也无所谓，重点是让注册表被覆盖一次。

坑二：dll 被进程占用，覆盖失败但错误被吞掉。部署脚本里先复制 dll 再注册，如果 dll 被某个正在运行的服务占着，复制会失败，但脚本没检查返回码，继续执行注册——注册的还是旧文件，看起来一切正常，实际跑的代码是旧的。所以部署脚本里每一步都要检查返回码，尤其是文件复制这一步。

坑三：杀毒软件的实时防护拦截注册表写入。注册动作会往HKLM\Software\Classes下面写大量键值，这在某些安全软件的启发式规则里是敏感行为，会被静默拦截。表现是"regsvr32 返回成功，但注册表里什么都没有"。排查方法是临时关掉实时防护重试一次，或者去看安全软件的拦截日志。

坑四：服务路径没加引号导致启动到了别的程序。如果 binPath 是C:\Program Files\App\svc.exe但没加引号，SCM 解析出来的可执行文件可能是C:\Program.exe，而参数是Files\App\svc.exe。这个错误在早期系统上是一个真实的安全问题来源。所以只要路径里有空格，就必须引号加转义，没有例外。

6. 工程化与免注册方案

前面讲的都是"手动操作"层面的东西，但实际项目里手动敲命令是不可维护的。这一节说说两种更工程化的思路。

6.1 安装包自动注册：能做，但要谨慎

大部分安装包制作工具（WiX、Inno Setup、NSIS 等）都提供了"注册 COM 组件"的能力。WiX 的做法是通过heat工具扫描 dll，把它里面的注册信息提取成静态的注册表项写进安装包。这涉及到一个重要的取舍。

微软从很早以前就把"自我注册"（self-registration，也就是安装过程中调用 dll 自己的 DllRegisterServer）标记为不推荐的做法。WiX 里的SelfRegCost属性早就被标注为废弃。原因有三条：一是自我注册需要在目标机器上执行组件自己的代码，安装过程变得不可预测；二是卸载时依赖 dll 自己的DllUnregisterServer，这个函数经常写得有 bug，导致卸载残留；三是权限模型不好控制，注册过程可能需要比安装本身更高的权限。

所以更稳妥的做法是：安装前用 heat 之类的工具把注册表项静态提取出来，安装包只负责写这些静态键值，不执行组件代码。这样做的好处是注册内容完全可审计、卸载能干净移除、安装过程也不需要额外提权。代价是 dll 里如果注册逻辑是动态的（比如根据环境判断写不同的键），静态提取就覆盖不了，这时候只能回到自我注册。

6.2 免注册 COM：一个值得考虑的替代路线

如果你的场景允许，其实有一条完全绕开注册表的路——免注册 COM（Registration-Free COM，也叫 Reg-Free COM 或 SxS 并行程序集）。

原理是在应用程序的清单文件（manifest）里，直接声明"我要用的 COM 组件在哪个 dll、它的 CLSID 是什么、ProgID 是什么、线程模型是什么"。运行时，Windows 的激活上下文会先查清单，命中就直接按清单里的路径加载 dll，完全不去查注册表。

一份简化后的清单结构大概是这样：

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity type="win32" name="MyCom.SideBySide" version="1.0.0.0"/> <file name="MyCom.dll"> <comClass clsid="{你的-GUID}" threadingModel="Apartment" progid="MyCom.Widget.1"/> </file> </assembly>

这份清单要嵌进调用方 exe 的资源里（通常是RT_MANIFEST资源、ID 1）。如果调用方不止一个，还得用<dependentAssembly>把这份清单作为依赖声明进去。

这条路的优势非常明显：不写注册表、不需要管理员权限、可以多版本共存（不同程序用不同版本的同一个组件）、绿色部署直接拷贝就能用。我见过不少内部工具用这个方案，效果很好。

它的限制也很明确，用之前必须确认：

• 只对显式声明了清单的进程有效。如果这个组件最终是被某个第三方宿主进程加载（比如被浏览器、Office、或者某个系统组件按 CLSID 拉起），那个进程的清单里没有你的声明，照样得走注册表。
• 跨进程编组依然需要类型库注册。如果你是进程内组件，没问题；如果真的要做 LocalServer32 那种跨进程 COM，编组信息和代理 dll 还是会牵扯到注册表。
• 调试体验稍差。清单里的 GUID 写错了，报错信息不会告诉你哪一行错了，只会在激活失败的时候给一个笼统的错误码。建议第一次配置的时候拿一个简单的宿主程序验证，确认清单结构和 GUID 都对。

我个人在内部小工具上的选择是：如果组件只被自己写的程序用，就优先走免注册路线，省心；如果组件要发布给外部方、或者会被系统或其他软件按 CLSID 拉起，那就老老实实做注册，并且把注册逻辑放进安装包里做成静态注册表项。这两种路线的分界线就是"调用方是不是我控制的进程"，判断清楚之后，选哪条路就不纠结了。