用 DSC 对 Windows 做声明式配置管理 —— 从 dsc.exe 开始的 IaC

新电脑的安装步骤文档、写着服务器搭建步骤的 Excel、离职者留下的祖传 BAT 文件 —— 直到今天，很多现场的 Windows 配置管理仍然靠“写着步骤的文档”和“执行步骤的脚本”在转。这种做法的弱点很清楚：步骤从执行的那一刻起就开始和现实脱节，而脚本在第二次执行时就会坏掉。

在 Linux 和云上，Terraform、Ansible 这类声明式的 IaC(Infrastructure as Code)早已是常态。那么，要用同样的思路去管理 Windows 客户端和服务器本身，该用什么呢？微软给出的答案是 DSC(Desired State Configuration)，而随着 2025 年被重写为不依赖 PowerShell 的命令行工具的 Microsoft DSC v3(dsc.exe) 出现，它终于变成了“可以正常上手”的样子。¹

目标读者是那些用步骤文档和脚本管理 Windows 电脑与服务器配置、希望转向声明式管理的开发者和信息化负责人。前提环境是 Windows 10/11 与 DSC 3.0 及以上版本，并以 PowerShell 的基本操作作为背景知识。难度为中级。

1. 先说结论

DSC 里写的不是“要执行的步骤”，而是用 YAML 写“应有的状态”。与当前状态的差异检测(test)和应用(set)由资源承担，所以同一份文件执行多少次都是安全的(幂等)，配置也变成了可以在 Git 上评审的数据。现在开始做的话，Microsoft DSC v3(dsc.exe)是唯一的选择。

步骤脚本和声明式配置的区别，体现在“坏的方式”上。写着步骤的脚本，对中途失败的电脑或已经设置完毕的电脑再跑一次，就会因为重复应用或报错而停下。声明式的配置只写了“应有的状态”，所以无论跑多少次、从什么样的中间状态开始跑，都会收敛到同一个结果。²

flowchart TB
    accTitle: 命令式步骤文档与声明式配置的对比
    accDescr: 命令式脚本自上而下执行步骤，因此重跑会造成重复应用或中断；而声明式的 DSC 声明应有的状态并只应用差异，所以执行多少次都会收敛到同一个状态
    imp["命令式：写步骤（BAT・步骤文档）"] --> i1["自上而下依次执行"]
    i1 --> i2["重跑会重复应用・报错"]
    dec["声明式：写状态（DSC）"] --> d1["检测与当前状态的差异"]
    d1 --> d2["只应用差异・跑多少次都安全"]

图1: 命令式脚本对“执行次数”很敏感，而声明式配置无论执行多少次都会收敛到同一个状态。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 17 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 理清“DSC”这个名字带来的混乱 —— 四个谱系

学习 DSC 时最先绊住人的，不是技术本身，而是搜索结果的混乱。叫“DSC”的机制一共有四个谱系，写法、执行方式和兼容性都不一样。³

Microsoft DSC v3 并不是把此前的 PowerShell DSC(PSDSC)简单更新一版，而是把对 PowerShell 的依赖切掉后重写出来的另一个产品。配置不再是 PowerShell 脚本而是 JSON/YAML 数据，资源可以用任何语言实现，并且在 Linux、macOS、Windows 上表现一致。¹

flowchart TB
    accTitle: DSC 四个谱系的系谱
    accDescr: 从 Windows PowerShell 5.1 内置的 PSDSC v1.1 派生出面向 PowerShell 7 的 PSDSC v2 和面向 Machine Configuration 的 PSDSC v3 预览版，而与它们分开、被重写为不依赖 PowerShell 的 Microsoft DSC v3 成为当前主角的关系
    v11["PSDSC v1.1（WinPS 5.1 内置）"] --> v2["PSDSC v2（PowerShell 7）"]
    v2 --> v3ps["PSDSC v3 预览版"]
    v11 -.->|"重写"| dsc3["Microsoft DSC v3（dsc.exe）"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["本文的主角"]

图2: 搜索“DSC”时，四个谱系的信息会混在一起出现。先分辨清楚一篇文章或一份资料讲的是哪个谱系，这一点很重要。

以下本文中写到“DSC”，指的都是 Microsoft DSC v3。旧世代的资产不会白费，这一点后面(第 6 节)会讲。

3. 声明式到底是什么意思 —— get・test・set 与幂等性

DSC 的核心概念是资源。资源针对“注册表值”“Windows 功能”“环境变量”这样每一类配置对象，提供状态的获取(Get)、判定(Test)、应用(Set)这几种操作。Get 是所有资源都要实现的。Test 对于没有自带实现的资源，由 DSC 用获取结果与声明的比较(合成测试)来代劳。Set 只有能强制状态的资源才会实现，像操作系统信息这类只读资源就没有。⁴ 使用者把“具体怎么设置”交给资源，自己只用数据写清“什么应该是什么样”。

正是这种分工带来了幂等性。在应用配置文档(dsc config set)时，DSC 会先对每个实例执行 test，只对不处于期望状态的实例调用 set。所以同一份配置应用多少次都是安全的。需要注意的是，单独对资源执行 dsc resource set 时总是会调用 set，是否有事前测试取决于资源自身的实现(implementsPretest)，这是二者的差别。⁵

flowchart TB
    accTitle: 由 get・test・set 构成的收敛循环
    accDescr: test 把配置文档里写的应有状态与当前状态做比较，没有差异就什么都不做，有差异则由 set 只应用差异，并可以用 get 确认结果，这就是幂等的收敛流程
    doc["配置文档（应有的状态）"] --> test["test：与当前状态比较"]
    test -->|"无差异"| ok["什么都不做（幂等）"]
    test -->|"有差异"| set["set：只应用差异"]
    set --> get["get：确认结果状态"]

图3: DSC 的应用是“先比较，再只改必要的部分”的循环，从此不必再纠结执行次数这个概念。

用代码来看它和命令式脚本的区别。比如“往注册表里写入这个值”这件事，在脚本里要自己把存在检查、创建、更新都分别写出来。

# 命令式:写“步骤”。分支和顺序全都要自己管理
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

在 DSC 里，同一件事写成“应有状态”的声明。没有存在检查，也没有分支。

# 声明式:写“状态”。怎么创建、怎么修正是资源的活
- name: 应用的运行模式
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

4. 装上 dsc.exe，单独调用资源试试

DSC 的安装方式有两种。要么从 GitHub 的 Release 下载压缩包解压后加入 PATH，要么在 Windows 上经由 Microsoft Store 源用 winget 安装。¹

# 从 Microsoft Store 源搜索并安装稳定版
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

装好之后，先列出本机可以使用的资源。

dsc resource list

在写配置文档之前，资源也可以一个一个单独调用。正是这种“可以小步试”的特性，让 v3 学起来轻松了不少。⁶

# 获取当前的状态(get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# 判定是否处于期望状态(test) ── 不做任何更改
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: dsc resource 命令的四种操作
    accDescr: dsc resource 命令之下挂着列出资源的 list、获取当前状态的 get、不做更改只判定是否处于期望状态的 test、以及应用状态的 set（仅限实现了 Set 的资源）这四种操作的结构
    cli["dsc resource 命令"] --> l["list：资源一览"]
    cli --> g["get：获取当前状态"]
    cli --> t["test：只判定・不更改"]
    cli --> s["set：应用（支持 Set 的资源）"]

图4: 不写配置文档也能单独调用资源。先只用 get 和 test 从观察开始，是安全的入门路线。

凡是伴随 set 的变更操作，以及处理 HKLM、系统设置的资源，都需要管理员权限。试手时从写入目标在用户名下(比如 HKCU)的例子开始，会比较稳妥。

5. 配置文档 —— 用 YAML 写“应有的状态”

把多个资源集中声明在一起的就是配置文档。它用 YAML 或 JSON 编写，至少要定义 $schema 和 resources 两项。每个资源实例都带有 name(在文档内唯一的显示名)、type(资源的完全限定名)、properties(期望的状态)。²

# standard-pc.dsc.config.yaml ── 标准客户端电脑应有的状态
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: 应用的运行模式
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

用上 parameters 和 variables，就能在一份文档里表达各环境之间的差异(比如按部门不同的设置值)。表达式的写法是 ARM 模板函数的一个子集。²

flowchart TB
    accTitle: 配置文档的结构
    accDescr: 配置文档由表示文档架构的 schema、吸收环境差异的 parameters 与 variables、以及资源实例数组 resources 构成，而每个实例都带有 name・type・properties 的结构
    docroot["配置文档（YAML / JSON）"] --> sch["$schema：文档架构的 URI"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources：实例的数组"]
    res --> inst["name・type・properties"]
    par -.-> inst

图5: 配置文档只是“架构+参数+资源声明”这样朴素的数据，而不是程序。

应用之前一定要先插入一步“观察”。dsc config test 不做任何更改就报告有没有差异，dsc config set --what-if 则显示“执行之后什么会改变”的预测。⁷

# 1. 确认有没有差异(不做更改)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. 预测显示应用之后会有什么变化(不做更改)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. 认可之后再应用
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. 确认应用之后的状态
dsc config get --file .\standard-pc.dsc.config.yaml

反方向也有入口。dsc config export 会针对用 --file 传入的输入文档中列举的资源(仅限支持 export 的资源)，生成一份包含系统上全部实例的配置文档并输出到标准输出。它可以作为把既有环境的现状记录下来的起点。⁸

# 传入列举了目标资源的输入文档，保存当前现状的配置文档
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

flowchart TB
    accTitle: 安全应用的四个步骤
    accDescr: 先用不做更改的 dsc config test 确认有没有差异，再用 dsc config set 的 what-if 选项预测显示变更内容，认可之后用 set 应用，最后用 get 确认结果的安全顺序
    t["dsc config test（有无差异）"] --> w["set --what-if（预测变更）"]
    w --> s["dsc config set（应用）"]
    s --> g["dsc config get（确认结果）"]

图6: 只要不打乱“观察→预测→应用→确认”的顺序，声明式配置的应用就不存在一锤定音的恐惧。

配置文档是数据而不是程序，这是它在运维上最大的优点。“这台电脑上应该设置了什么”可以作为 YAML 的差异被评审，变更历史本身就成了配置的变更历史。

6. 让既有资产继续发挥价值 —— PSDSC 资源的适配器与 WinGet Configuration

一听说“v3 是另一个产品”，难免担心过去的资产，但 DSC v3 可以通过适配器资源这个机制调用旧世代的 PSDSC 资源。按 DSC 3.2 及以上的现行名称，面向 PowerShell 7 基于类的资源是 Microsoft.Adapter/PowerShell，面向 Windows PowerShell 5.1 基于 MOF、基于脚本的资源是 Microsoft.Adapter/WindowsPowerShell(此前的名字是 Microsoft.DSC/PowerShell 和 Microsoft.Windows/WindowsPowerShell)。⁹ 多年积累下来的 PSDSC 资源生态，可以从 v3 的配置文档直接触达。

另一个连接点是 WinGet Configuration。在 PC 装机的文章里介绍过的 .winget 文件，从 v3 架构(WinGet 1.11 及以上)开始已经直接把 DSC v3 当作处理引擎来用。只要在配置文件的 metadata 中把处理引擎指定为 dscv3，文档的内容就是 DSC v3 的配置文档本身。¹⁰

# WinGet Configuration v3 ── 内容就是 DSC v3 的配置文档
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: 应用的运行模式
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

这里有一处需要注意的地方。既有的 v2 格式(用 properties.configurationVersion: 0.2.0 并把资源放在 properties 之下的写法)文件，并不能原样在 dscv3 处理引擎上运行。v2 文件仍会在原来的处理引擎上继续工作，但要放到 DSC v3 上，就要按照官方的转换指南(示例仓库里的“Convert to v3”)迁移写法。¹⁰

flowchart TB
    accTitle: 以 DSC v3 为中心的分层结构
    accDescr: winget configure 或 Azure Machine Configuration 这样的编排层调用 DSC v3，DSC v3 直接调用原生资源，而既有的 PSDSC 资源则经由适配器资源调用的分层结构
    orch["winget configure・Machine Configuration"] --> dsc["dsc.exe（DSC v3）"]
    dsc --> native["原生资源（Registry 等）"]
    dsc --> adapter["适配器资源"]
    adapter --> psdsc["既有 PSDSC 资源（PowerShell 资产）"]

图7: DSC v3 既是一个独立的工具，同时也是 winget、Azure 这些上层工具的共同基础。既有的 PSDSC 资产就挂在适配器之下。

也就是说，用 v3 学到的知识和写下的配置，在手边的 dsc.exe 上、在装机用的 winget configure 上、在云端管理的 Machine Configuration 上都通用。这不是重新学，而是汇流。¹

7. 让它跑在日常运维里 —— 用 Git 管理，检测漂移

配置文档的存放地点要选Git 仓库。这样一来，配置变更就走上了“用拉取请求评审、合并、再应用”这条和软件开发一样的流程。步骤文档忘了更新这个概念本身就消失了。

应用之后的课题是配置漂移(有人手动改了设置，于是渐渐偏离应有的状态)。在 DSC 里，漂移检测就等于定期执行 dsc config test。test 不做任何更改，所以能把检测和修复分开，这是很重要的性质。先只把检测自动化，修复(set)则等看清差异内容之后再做，这才是稳妥的做法。

# 定期执行用:区分 test 本身的失败、单个资源的错误和漂移，三者都以非零退出
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "dsc config test 的执行本身失败了(退出码: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # 文档校验失败或部分资源以非零退出。检查没有跑完，不能报告为健康
    Write-Error "部分资源的检查出错了。请确认 messages"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "检测到配置漂移"
    exit 1
}

定期执行的载体，在客户端电脑上可以用任务计划程序(无人执行的设计在另一篇文章里讲解)，在成组的服务器上可以用 CI 运行器。如果组织已经把管理集中到 Azure，那么 Machine Configuration 就是一个托管的承接方，能对 Azure VM 和经由 Azure Arc 纳管的本地服务器做审计与应用。¹¹

flowchart TB
    accTitle: 以 Git 为起点的配置管理运维循环
    accDescr: 放在 Git 仓库里的配置文档先经拉取请求评审再应用，由任务计划程序或 CI 定期执行 test 检测漂移，确认差异后或者修复、或者回到更新配置的循环
    git["Git 仓库（配置文档）"] --> pr["变更用拉取请求评审"]
    pr --> apply["用 dsc config set 应用"]
    apply --> sched["定期执行：dsc config test"]
    sched -->|"检测到漂移"| judge["确认差异并判断如何处置"]
    judge -.->|"配置是对的"| fix["用 set 修复"]
    judge -.->|"现实是对的"| git

图8: 应对漂移的手段不只有“修复”。如果现场的变更是对的，那么改掉配置文档再合并，才是声明式管理的规矩。

图8 右下角的分支很容易被忽略。漂移并不总是“恶”，有时只是现场必需的变更还没有写回配置而已。这种时候不该把电脑改回去，而应该让配置文档去贴合现实。权威始终在 Git 里的声明——只要守住这条纪律，无论倒向哪一边，管理都不会崩。

8. 限制与坑

把上手之前该知道的限制如实列出来。

没有 LCM。 v1.1 里的 LCM(Local Configuration Manager)是一个常驻代理，它会保存配置并做定期应用和自动修复。v3 是“只在被调用时才动的命令”，不会作为服务常驻。¹ 如果需要持续强制，就得像上一节那样自己选择执行的载体(任务计划程序、CI、Machine Configuration)。这不是退化，而是把“如何触发执行”开放给现代工具的设计变更，不过带着 v1.1 的 pull server 那套感觉过来的人，确实会一时不适应。

管理员权限的处理。 涉及整台机器的资源(HKLM、Windows 功能等)在 set 时需要提权，通过适配器使用 Windows PowerShell 系的 PSDSC 资源时也以管理员身份运行为前提。⁶ 在写配置文档的阶段就把按用户的设置和按机器的设置分开，执行上下文的设计会轻松很多。

不要把机密写进配置。 配置文档是要放进 Git 的数据。不要把密码和 API 密钥直接写死，而应该做成参数化、在执行时传入的设计。

别人的配置文件要读过再执行。 配置文档拥有通过资源改变系统的能力。从公开仓库拿到的 .winget 文件和配置文档，要先确认内容以及所引用资源的可信度，然后再应用。这是官方文档也明确警告过的运维必修项。¹²

flowchart TB
    accTitle: v1.1 的 LCM 常驻型与 v3 的命令型的对比
    accDescr: PSDSC v1.1 里由常驻的 LCM 保存配置并负责定期 pull 和自动修复，而 DSC v3 只是作为命令被启动，因此定期执行的载体要从任务计划程序、CI、Machine Configuration 中自己挑选并准备
    v1["PSDSC v1.1：LCM 常驻"] --> pull["保存配置并定期 pull・自动修复"]
    v3["DSC v3：只以命令启动"] --> push["执行的载体自己准备"]
    push -.-> ex["任务计划程序・CI・Machine Configuration"]

图9: v3 里没有“记住配置并擅自替你修好的某个人”。把这看作不便，还是看作重新拿回了执行控制权，正是设计上的分水岭。

9. 小结 —— 把步骤文档换成仓库

• 现在才开始做 Windows 的声明式 IaC，就用 Microsoft DSC v3(dsc.exe)。请始终留意，你正在读的资料属于四个“DSC”谱系中的哪一个。³
• DSC 用 YAML/JSON 写的不是“步骤”而是“应有的状态”，由 test(比较)与 set(应用差异) 保证幂等的收敛。先从 dsc resource get/test 的观察开始，再用 --what-if 确认影响，最后应用，这个流程是安全的。⁷
• 既有的 PSDSC 资源经由适配器、装机用的 .winget 资产经由 WinGet Configuration v3 架构，都能汇入 v3 的世界(v2 格式的文件需要按转换指南迁移写法)。⁹¹⁰
• v3 里没有 LCM。把配置的正本放在 Git 上，用定期执行的 dsc config test 检测漂移，再按“配置是对的就修复、现实是对的就更新配置”的纪律转起来，这就是运维的骨架。

步骤文档的宿命，就是从写下的那一刻起便与现实渐行渐远。声明式的配置管理，把这种偏离变成了“能被检测出来的差异”。先把自己电脑上的几个设置写成配置文档，跑一遍 dsc config test 试试吧。你应该能体会到步骤文档正在被仓库取代的感觉。

相关文章

• 用 winget + PowerShell 自动化 PC 装机 —— 让步骤文档变得可执行
• 该不该把 BAT 迁移到 PowerShell —— 判断标准与迁移实务
• 任务计划程序的任务不执行、以 0x1 结束 —— 原因排查与安全的运维设计
• 从 GPO 迁移到 Intune 的指南 —— 中小企业的现实解
• WSUS 被弃用之后的 Windows Update 管理

相关的咨询领域

小村软件合同公司为大家提供以下支持：Windows 电脑与服务器配置向声明式管理的迁移、装机与公司内部标准环境的自动化，以及把属人化的步骤文档变成可执行的东西。

• 技术咨询・设计评审
• 既有 Windows 软件的改造与维护
• 既有资产活用・迁移支持
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

DSC 好像有好几个版本，我该用哪一个？

如果你现在才开始做声明式配置管理，就用 Microsoft DSC v3(dsc.exe)。DSC 一共有四个谱系：内置于 Windows PowerShell 5.1 的 PSDSC v1.1、面向 PowerShell 7 的模块 PSDSC v2、用于 Azure Machine Configuration 的 Linux 支持的 PSDSC v3(预览版)，以及被重写为不依赖 PowerShell 的独立命令的 Microsoft DSC v3。v3 是跨平台的，配置不再写成 PowerShell 脚本，而是写成 YAML/JSON 数据，已有的 PSDSC 资源也可以通过适配器继续复用。搜索时加上“DSC v3”“dsc.exe”，更容易把旧世代的资料区分开。

DSC v3 和步骤脚本(BAT 或 PowerShell)有什么不同？

步骤脚本写的是“要执行的步骤”，所以为了第二次执行时不出现重复应用或报错，幂等性得由你自己做进去。DSC 把“应有的状态”写成数据，与当前状态的比较(test)和差异的应用(set)由资源承担。同一份配置文档执行多少次都不要紧，对于已经处于期望状态的项目它什么都不做，因此可以不必在意执行次数地分发和重跑。而且配置本身就是 YAML 数据，用 Git 做差异评审和版本管理比脚本容易得多。

已有的 PowerShell DSC 资源和 WinGet Configuration 资产会白费吗？

不会白费。DSC v3 可以通过适配器资源(DSC 3.2 及以上为 Microsoft.Adapter/PowerShell 与 Microsoft.Adapter/WindowsPowerShell，此前则是 Microsoft.DSC/PowerShell 与 Microsoft.Windows/WindowsPowerShell)调用基于类和基于 MOF 的既有 PSDSC 资源。另外，WinGet Configuration 从 v3 架构(WinGet 1.11 及以上)开始已经把 DSC v3 当作处理引擎来使用。既有的 v2 格式 .winget 文件仍然可以在原来的处理引擎上运行，但要放到 DSC v3 的处理引擎上，就需要按照官方的转换指南改写成 v3 格式。

用 DSC v3 怎样才能“持续地”强制某个配置？

DSC v3 本身是一个以命令方式启动的工具，它没有 v1.1 里 LCM(Local Configuration Manager)那样的常驻代理和自动修复机制。如果需要持续地应用和审计，就自己用任务计划程序或 CI 定期执行 dsc config test 来检测漂移，或者放到 Azure 的 Machine Configuration(通过 Azure Arc 也能纳管本地服务器)这类编排层上。

直接执行 dsc config set 让我有点害怕，能事先确认影响吗？

可以。执行 dsc config test，就能在不做任何更改的前提下确认哪些资源实例不处于期望状态。此外，dsc config set 还有 --what-if 选项，可以在不实际更改的情况下显示“执行之后什么会怎样改变”的预测。先用 test 和 --what-if 看清差异，确认没问题再执行 set，这个顺序是安全的。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。