如果你在团队里负责开发环境的管理或者经历过“换台电脑配环境搞了一天、同事的环境跑不起来、一个项目引用的依赖版本没人说得清”这种场景那这篇文章大概率能帮到你。Microsoft Dev Box 是微软在 Azure 云平台上推出的开发者虚拟机服务核心是一台为开发定制好的 Windows 虚拟机VM。它把开发环境从本地电脑里剥出来放到云上你只要用任意设备连过去拿到的就是和办公室完全一致的开发工作站。本文我会从产品定位、底层架构、创建流程到实际使用中的坑拆开讲一遍适合正在评估云端开发环境的技术负责人也适合想给日常开发配一台“备份电脑”的开发者。1. 先弄明白 Dev Box 到底是什么1.1 从“到处找开发环境”的痛点说起先说个真实场景。你在公司主力机上装了一整套环境Visual Studio、SQL Server、各种 SDK、内部工具、私有 NuGet 源配置。某天你去客户现场临时改个 Bug客户端电脑上没有这些你只能开远程桌面回公司电脑卡顿先不说公司网络策略一收紧你连家都没了。再或者团队来了个新同事入职第一天就在装环境装到下午还在等 Xamarin 组件下载产出的第一个小时被环境配置吃掉了。这就是开发环境“本地化”的代价。每个人的机器配置不一样系统版本不一样预装软件不一样哪怕团队有环境文档也总有人漏装一个运行库、踩到一个奇怪的注册表冲突。Dev Box 要解决的正是这件事把开发环境变成云上一个可复制、可统一、可随时重建的“开发电脑”。它不是又一台虚拟机而是从微软 Azure 云平台上直接提供的、按开发者使用习惯定制的 Windows VM。所有开发者连接到各自云上的 Dev Box体验上就像操作一台本地 Windows 电脑但底层运行在 Azure 的数据中心里。这个思路和“拿服务器当桌面”不是一回事。Dev Box 的目标用户是写代码的人不是普通办公用户所以它默认预置了开发工具链并且在网络接入、身份认证、项目管理上加了大量面向开发者的工作流设计。1.2 一张表分清 Dev Box 和它的“亲戚们”刚接触云桌面的人很容易把几个概念混在一起尤其是 Dev Box、Azure Virtual DesktopAVD、GitHub Codespaces 以及你自己电脑上的虚拟机。我把它们的区别整理成一张对照表一眼就能看明白。服务本质适用场景和 Dev Box 的核心差异Microsoft Dev Box云上的 Windows 开发工作站由 Azure 托管 VM 承载带完整开发工作流长期/中期开发环境重负载桌面级开发Windows 平台开发专为开发者设计镜像、项目、关闭计划都围绕开发场景Azure Virtual DesktopAVD多用途 Windows 桌面虚拟化普通办公、外包、远程桌面场景更偏向固定桌面池和通用办公不为开发工具链做预配GitHub Codespaces浏览器里的 Linux 容器开发环境轻量开发、网页前端、GitHub 生态内协作不是 Windows 桌面不适合 Win32/WPF 等桌面开发本地虚拟机 / Windows Sandbox在你当前电脑上用虚拟化软件开的机器临时跑马、测不信任软件受宿主机硬件与网络限制无法解决远程访问需求普通 Azure VM通用 IaaS 虚拟机你自己搭基础设施、跑服务、当服务器用网络、RDP、镜像、补丁几乎都要自己管没有项目化体验所以如果你只是想要一台 Windows 虚拟机普通 Azure VM 完全够用如果你要的是“一群开发者每个人都能快速拿到标准开发环境用完还能回收”Dev Box 才是更贴近需求的那一个。它本质上仍然是 VM但多了一层“开发者工作流”的包装这正是它与裸虚拟机的分水岭。1.3 四个必须理解的核心概念要上手 Dev Box有四个词绕不开Dev Center、Dev Box Definition、Dev Box Pool、Network Connection。我刚开始也是一头雾水后来发现它们之间就是很清晰的层级关系。Dev Center开发中心所有 Dev Box 资源的顶层管理容器。你在这里配置网络、创建项目、统一管理镜像和许可。Dev Box Definition定义一个“镜像 计算规格”的组合。比如“Visual Studio 2022 企业版 Windows 11 企业版 16 核 64GB 内存”它就是一台 Dev Box 的配方。Dev Box Pool池一组使用同一份定义、位于同一网络环境的 Dev Box 集合。开发者从这个池里“捞”出一台自己的机器。Network Connection网络连接决定 Dev Box 连到哪个虚拟网络、使用哪组 DNS 和域配置。这是接入公司内网资源的关键。用一个日常类比Dev Center 是总店Definition 是菜谱Pool 是后厨产线Network Connection 是食材供应链。开发者不需要关心后厨怎么运转只要从某个 Pool 里“点一杯”就能拿到一台环境一致的工作站。这里还有个容易被忽略的角色叫 Project项目它位于 Dev Center 之下用来把不同的 Pool 和开发者按项目组织起来方便做权限隔离与配额管理。2. 深入底层Dev Box 和 Azure 虚拟机的关系2.1 底层就是 Azure VM但不是“让你自己去开一台 VM”从技术实现来看Dev Box 的底座就是 Azure 上的 Windows VM。它有虚拟 CPU、内存、托管磁盘跑的是 Windows 11 企业版或 Windows 10 企业版多会话版本本质上和你手动在 Azure Portal 里创建一台 VM 没有硬件上的区别。但关键在于Dev Box 把普通 VM 需要你亲手处理的部分全部封装掉了。如果自己开一台 Azure VM你要操心的事是选镜像、配公网 IP 还是内网 IP、打开 RDP 端口、加入域、装 Visual Studio、装各种 SDK、打补丁、做备份、担心资源被其他同事误删……而 Dev Box 的模型里平台替你管好了预配、域加入、远程桌面访问和生命周期。你要做的只是选择一份定义点击创建等它变成 Ready然后远程登录。这也带来一个很重要的区别普通 VM 是“长期资产”你通常舍不得随手删掉Dev Box 是“容易破碎也容易重建的工作台”删掉重来成本很低。我建议所有使用者把 Dev Box 当成一种“临时但完整”的环境来对待代码和文档必须同步到 Git 或共享存储机器本身随时可以被丢弃。这种心态能避免很多人把云桌面用成“另一台本地电脑”之后的混乱。2.2 镜像管理环境标准化与复制Dev Box 最值钱的地方之一我觉得是镜像管理。微软在 Azure Marketplace 里提供了预置好的镜像例如“Visual Studio 2022 Enterprise on Windows 11 Enterprise”开箱就带 Visual Studio、Windows SDK、常用组件。你不需要在企业里再花时间在基础镜像上团队可以直接基于官方镜像起步。真正要投入精力的是自定义镜像。当一个团队沉淀出固定的依赖后比如统一的 Node 版本、内部证书、数据库连接工具、特定版本的 Visual C 运行库你完全可以把这些固化成自定义镜像存到 Azure Compute Gallery镜像库里。之后所有新建的 Dev Box 都从这个镜像出来环境的一致性就保证了。这里有一个我自己踩过的坑自定义镜像不是“越全越好”。有人喜欢把所有可能的 SDK 都装进镜像结果镜像体积涨到几百 GB每次创建 Dev Box 都要等很久而且软件之间还可能互相冲突。我更推荐“按角色做镜像”的做法前端组一个镜像.NET 服务端一个镜像数据组一个镜像。镜像里只放该角色高频使用的东西低频或一次性工具让开发者在自己的 Dev Box 里手动安装并在团队文档里记录。2.3 网络与身份Dev Box 如何接入企业环境很多团队评估 Dev Box 时最担心的问题就是开发者需要访问公司内网的数据库、内部测试环境或私有 NuGet 源云上的虚拟机能不能连过去答案是通过 Network Connection 实现。你在创建 Dev Center 的时候可以指定一个已有的虚拟网络和子网把所有 Dev Box 都接入这个网络。只要 Azure 网络和公司内网之间有合法的链路通道比如站点到站点连接、ExpressRoute 或内网 DNS 转发Dev Box 就能以企业网络成员的身份访问内部资源。身份层面Dev Box 深度集成 Entra ID原名 Azure Active Directory。开发者用企业账号登录不需要额外维护一套用户名密码。管理员可以在 Entra ID 里做条件访问策略要求多因素认证、限制登录 IP、管控设备的合规状态。这一点对安全要求比较高的团队非常友好它和普通 VM 的“本地管理员密码”模式完全不是一个层级。另一个容易被忽略的点是磁盘加密和合规。Dev Box 使用的是 Azure 托管磁盘平台侧支持加密。如果你的行业有严格的数据安全要求管理员还可以通过 Azure Policy 限制开发者从 Dev Box 往外复制敏感数据或者干脆禁用 USB 重定向、剪贴板传输等功能。这些能力在自建 VM 时需要做一堆额外配置在 Dev Box 里是可以通过策略批量下发的。2.4 为什么不直接用普通 Azure VM 给每个人开一台这是我被问到最高频的问题。答案其实不复杂普通 Azure VM 缺少“开发者工作流”。你可以用 ARM 模板自动部署一批 Windows VM可以写脚本批量装软件甚至可以把 RDP 端口暴露出来让人连。但接下来你要自己处理一连串问题用户密码怎么管不同项目的人怎么隔离下班了机器怎么自动关一个月之后怎么统计哪些 VM 还在用某位开发者的 VM 磁盘坏了你怎么重建并且不留旧环境残留这些问题每一个单独看都不难但合在一起就是巨大的运维负担。Dev Box 把这一整条链路抽象好了按项目组织、按 Pool 分配、自动启动/停止策略、通过开发者门户让用户自助创建自己的机器、管理员用统一视图监控使用情况。对 IT 管理员来说这不是省了一点事而是把“管理开发环境”从工程问题变成了策略问题。当然它的代价是灵活性比裸 VM 低一些。如果你的场景需要高度自定义的脚本编排、特殊网络拓扑、非常规磁盘配置那普通 Azure VM 反而更合适。两者不是替代关系是不同需求下的选择。3. 从零创建一个 Dev Box实操过程3.1 前置条件账号、权限和可用区域在开始创建之前先把前置条件检查一遍能省掉后面一大半麻烦。首先你需要一个 Azure 订阅。Dev Box 并不是免费服务不同订阅类型、不同许可模式下成本结构会不一样。最常见的组织使用方式是管理员把用户加入某个 Project并授予“Dev Box User”角色用户登录 devbox.microsoft.com 门户后就能看到自己有权创建的 Pool。需要说明的是Dev Box 的使用资格与订阅权益有关系实操前先确认你的订阅套餐或 Visual Studio 授权是否包含该服务具体以微软官方许可页和价格计算器为准。其次要考虑区域。Dev Box 的可用性和价格在不同 Azure 区域有差异建议选择离团队成员较近、且能和你现有内网资源连通的区域。目标是降低远程桌面延迟。过高的延迟会让鼠标拖拽、代码补全都带“飘”的感觉体验差很多。如果你有华东或华北团队优先选亚洲区域的机房不要为了便宜选一个距离过远的区域。最后准备好虚拟网络。如果你已经规划好网段直接使用现有 VNet如果没有可以新建一个简单的 VNet比如10.1.0.0/16再划分一个子网用来放 Dev Box。网络问题看似可以后补实际上新建 Dev Center 时就需要绑定网络连接所以建议提前半个月就把网络方案定下来。3.2 创建 Dev Center 并配置 Network Connection进入 Azure Portal搜索“Microsoft Dev Center”进入创建页面。创建时需要指定资源组、名称和区域。区域一旦选定后面这个 Dev Center 下的资源最好都放在同一区域否则可能出现网络延迟或数据传输费用问题。创建完 Dev Center 后下一步是配置网络连接。操作路径大致是在 Dev Center 资源里找到“网络配置”或“Network Connection”选择已有的 VNet 和子网填写 DNS 服务器地址。如果企业环境需要加入 Active Directory 域这一步也要把域信息填好。这里多说一句不要在子网里再放一堆其他生产服务器开发环境的网络流量比较大和业务资源混在一起容易互相影响也不利于安全隔离。配置完成后一定要等状态的健康检查通过。网络连接创建失败、DNS 配置错误、子网网段冲突都会直接导致后续创建的 Dev Box 无法正常启动或无法解析内网域名。我见过有人在网络连接还是“Failed”状态时继续往下配 Pool结果创建出来的机器一台连不上排查了半天才发现是子网网段选错了。网络连接的健康检查是进入下一道工序前必须过的关卡。3.3 创建 Project、Definition 和 Pool整体顺序是Dev Center 下面先建 Project项目下再建 Pool一个 Pool 绑定一个 Dev Box Definition。原因是 Dev Box 的资源通常按项目隔离权限也按项目下发。创建 Dev Box Definition 时你要做两个选择镜像和计算规格。镜像可以直接用 Azure Marketplace 里的“Visual Studio 2022 Enterprise on Windows 11 Enterprise”也可以选择你自己构建的自定义镜像。计算规格的选项比较多我给出了一个常规场景参考表但不是唯一答案。开发场景建议规格说明Web 前端、轻量后端开发8 vCPU / 32 GB 内存性能够用成本相对可控.NET 中型解决方案、微服务调试16 vCPU / 64 GB 内存编译速度明显提升大型 WPF / WinForms / Unity 项目16 vCPU / 64 GB 以上加 SSD 数据盘资源和 IO 压力都比较大数据工程、BI、测试环境模拟16 vCPU / 64 GB 或更高取决于数据量和查询负载创建 Pool 的时候除了选择 Definition还可以绑定自动停止计划。这里我强烈建议一开始就设置好关机时间比如工作日晚上 8 点之后自动关机。开发人员很少记得主动关机如果一直开机Azure 帐单会非常可观。创建完成之后管理员还需要把使用者添加到这个 Project 并分配角色。很多人会卡在这里Pool 建好了但用户登录 devbox.microsoft.com 看不到这个 Pool因为用户没有分配到对应的“Dev Box User”角色。别问我怎么知道的我也经历过这种“看得到项目但找不到入口”的尴尬。3.4 启动并连接你的 Dev Box管理员配好后普通开发者的操作非常简单。打开 devbox.microsoft.com用企业账号登录选择你有权限的 Project 和 Pool点击创建然后等待状态变成 Ready。首次创建的时间取决于镜像大小和区域当前负载内置的 Visual Studio 镜像一般需要几分钟到十几分钟不等如果用的是很大的自定义镜像可能更久。连接方式是远程桌面。你可以在开发者门户下载.rdp文件用 Windows 自带的“远程桌面连接”打开也可以使用 Microsoft Remote Desktop 应用Windows / macOS / iOS / Android 都有。首次连接后系统和普通 Windows 工作站几乎一致——桌面、开始菜单、文件资源管理器、Visual Studio 都在。开发者接下来做的事情就是装 Git、克隆代码、打开解决方案和用本地电脑没有太大的体验差异。有一个使用小技巧开发者在远程桌面里可以做本地磁盘映射把自己电脑的某个盘符挂载到 Dev Box 里方便临时拷贝文件。但如果公司安全策略比较严格管理员可能会禁用这个功能。另外建议所有敏感项目代码不要只存在于 Dev Box 本地磁盘务必尽快推到 Git 远端因为云上的虚拟机随时可能被重建磁盘只应该被当作“运行环境”而不是“备份仓库”。3.5 团队默认工作流与第一天体验当一个新成员加入团队他拿到 Dev Box 后第一天应该干什么如果团队已经沉淀了自定义镜像那什么都不用装只要登录、克隆代码、跑通一个最小示例就行。这个体验比“入职第一天配环境”要顺畅太多。对于还没有自定义镜像的团队我的建议是先让开发者在预置镜像基础上手动补全依赖同时在团队 Wiki 里记录“必备安装项”比如特定版本的 Git、Node.js、内部证书、数据库客户端工具、MySQL ODBC Driver、某些传统桌面工具依赖的 Microsoft Visual C Redistributable 包。等记录足够稳定再把这些项封装进自定义镜像。这里还要提醒一点Dev Box 不是构建服务器不建议长期用来跑 CI 流水线。它本质上是一个交互式开发工作站适合人来使用。虽然装构建工具、跑长时间任务没问题但把高频构建任务放在 Dev Box 上会占用这台机器的 CPU 和网络影响开发者正常使用而且成本也不划算。构建任务交给 Azure DevOps 或 GitHub Actions 里的独立代理更合适。4. 花钱和运营成本控制与落地经验4.1 规格选型别一开始就选最便宜的很多团队第一次评估 Dev Box 时为了控制预算会先从最小规格开始试。这个思路本身没有错但要注意区分“试用”和“正式用”。如果是给前端组做轻量开发4 vCPU / 16GB 的内存配置勉强够用但如果要编译大型 .NET 解决方案8 vCPU / 32GB 都只能算入门大型项目在编译高峰期吃满 64GB 内存一点都不意外。我的经验是正式投入使用前先用一个“最接近实际负载”的项目做一次编译测试。让团队里资深的开发者用目标规格跑一次完整构建观察 CPU 峰值、内存占用、磁盘等待时间。如果内存占用经常冲到 90% 以上就说明规格不够不要心存侥幸。云上资源升级很容易但频繁升级会打断使用而且前期的数据迁移、软件重装成本也得算进去。磁盘方面也值得注意。Dev Box 底层使用 Azure 托管磁盘默认的性能取决于磁盘类型。对开发场景来说IOPS 通常比容量更关键尤其是前端项目里大量小文件、Node 模块加载、包管理器解压这些操作非常吃随机读性能。建议选择 Premium SSD 或更高级别的磁盘并适当把临时目录、构建缓存目录放到数据盘上减少对系统盘的写入压力。4.2 成本估算与关闭计划云开发环境的成本大头是计算资源。Dev Box 按小时计费关机状态下计算费用会停止但磁盘存储费用仍然存在。所以成本控制的核心原则只有一条让该关机的机器乖乖关机让长期不用的机器消失。我习惯用一个很简单的公式来做估算单台月成本约等于“每小时价格 × 开机小时数 × 当月天数”再加上“磁盘容量 × 单位存储价格”。举例来说如果一台 16 vCPU / 64GB 的实例每小时价格约 1 美元实际价格以区域为准一台机器全天 24 小时开机30 天就是 720 小时计算费用就到 720 美元上下如果设置了工作日每天 10 小时开机策略开机时长大约 220 小时计算费用就降到 220 美元左右节省幅度超过 60%。这里的数字只是示意真正做预算时请用 Azure 价格计算器按你的区域实时核对。策略月开机时长成本量级示意适用情况全天候开机约 720 小时高不推荐除非有特殊需求工作日 8 小时约 176 小时中标准办公作息工作日 10 小时并自动关约 220 小时中常见开发节奏按需启动长期不用删除不定低临时任务、外包协作关闭计划是在 Pool 层面配置的创建 Pool 时就能绑定。如果你的团队有加班习惯也可以让开发者在需要时手动启动机器不限制过死。但一定要定期检查“是否有人把机器一直开着”。我建议管理员每个月导出一次 Dev Box 使用报告找出连续多日都在开机的实例逐一确认是否还是工作所需。这比到月底看账单震惊一下要强得多。4.3 推行 Dev Box 的几个实操建议第一先试点再面向全团队推广。选 1 到 2 个技术栈统一、对云端环境兴趣较高的项目组先跑一个月记录他们遇到的问题网络延迟、软件兼容性、磁盘 IO、登录权限等。这些问题在试点期解决掉全量推广时的阻力会小很多。第二把自定义镜像的维护放到日程上。镜像不是建一次就完事系统补丁、SDK 升级、证书更新都需要定期做。我的建议是每季度做一次基础镜像更新每半年邀请核心开发者评审镜像清单删掉没人用的组件加上新项目的依赖。第三明确“个人数据与代码”的边界。Dev Box 是标准化环境它不适合存放个人照片、视频、大型下载文件。团队规则里最好写清楚代码必须进 Git临时文件放共享盘数据库备份走正规备份流程。否则一旦机器被重新部署或删除个人数据丢失的锅最终还是要管理员来背。第四把权限和合规方案前置。你在试点阶段就要想好哪些人能用 Dev Box能创建几个并发实例是否允许复制文件到本地是否需要额外磁盘加密。这些策略在 Entra ID 和 Azure Policy 里都可以配越早确认越少返工。5. 常见问题与排错实录5.1 连不上、卡启动、黑屏Dev Box 创建后一直处于“Provisioning”或“Starting”状态这是新手最容易遇到的现象。常见原因有三个Pool 所在区域资源不足、自定义镜像体积太大导致复制缓慢、或者订阅配额不够。排查顺序建议是先看 Pool 的配额设置再看镜像大小最后检查 Dev Center 的健康状态和区域可用性。网络连接不健康导致无法连接通常会给出错误提示。如果 RDP 端口被网络安全组规则挡掉了可以在 Azure Portal 里检查相关子网绑定的 NSG 规则确认是否放行了远程桌面流量。注意很多团队为了安全会全局禁用 3389 端口但 Dev Box 的远程连接走的是 RDP 网关通道不完全等同于裸 RDP不要用普通 VM 的思维乱加禁止策略否则会误伤整个 Pool。连接后黑屏是另一个常见现象。优先尝试在开发者门户里重启 Dev Box如果重启无效就检查本地 RDP 客户端的凭据缓存清掉重置后再连。最不济的方案是删除重建 Dev Box。只要代码都在 Git 远端删除重建只是一种“伤害最小的修复手段”。5.2 开发环境里的软件依赖问题这部分是实际使用中最琐碎、也最容易让人抓狂的。很多老牌 Windows 开发工具运行起来依赖“Microsoft Visual C Redistributable”运行库不同版本、不同架构x86 / x64都有对应版本。如果工具启动时报缺少运行库先确认安装包是 32 位还是 64 位再安装对应架构的 Redistributable 包。不要图省事只装 x64很多老插件是 x86 的。WebView2 Runtime 的问题也经常出现。现在不少工具用 WebView2 内嵌浏览器如果它运行异常表现是窗口空白、登录面板打不开等。大多数情况下到“设置”中找到 WebView2 Runtime 修复一下即可如果修复不了可能是企业组策略限制需要联系管理员检查本地策略。安装软件时遇到“错误 1603”通常与 MSI 安装器执行失败有关权限不足、安装缓存损坏、同版本旧软件残留注册表冲突都可能触发。先尝试以管理员身份运行安装包再不行就使用微软官方的“程序安装和卸载疑难解答工具”清理残留最后复查是否缺少前置运行库。这几个步骤能解决 90% 以上的 1603 报错。还有一类隐藏比较深的坑是数据库驱动。比如 SQL Server 2012 客户端组件和 MySQL ODBC Driver版本不匹配时接口能装上但程序里连不上数据库报一些很难理解的错误。遇到这种情况直接到微软下载中心或数据库厂商站点下载对应官方组件不要用第三方整合包并记录安装版本到团队 Wiki。5.3 权限、账户和本地化问题最典型的问题是用户明明被加了进来但登录 devbox.microsoft.com 后看不到任何 Pool。解决办法就是检查角色分配管理员需要把用户加入对应 Project并分配“Dev Box User”角色。这个角色不是继承自动来的不分配就没有入口。登录时如果提示账户没有许可证或订阅不可用通常是组织配额或订阅权益问题。这里需要提醒Dev Box 的使用权益和不同级别订阅绑定务必确认你所在组织的订阅类型包含该服务。这不是技术人员能自己解决的需要和采购或 IT 管理员提前对齐。另外一个容易忽略的是时区问题。Dev Box 创建在云端默认区域和本地时区可能不一致。团队里如果有统一策略把时区锁定为 UTC个人开发者会感觉“时间不对”。这种问题通常需要管理员在镜像或策略层面统一设置不建议每个人在虚拟机里手动改因为一旦机器重建又会回到默认状态。5.4 磁盘空间和关机策略不生效磁盘空间不足是云开发工作站的老大难。Visual Studio、缓存、Docker 镜像、NuGet 包动辄几十 GB。我的建议是把构建缓存目录、包缓存目录尽量转移到容量更大的数据盘并定期清理Temp临时目录。如果磁盘还是不够优先考虑加数据盘而不是把系统盘规格调大因为系统盘扩容操作往往更麻烦。关机策略不生效通常和 Pool 上的自动停止计划配置有关。注意策略修改后已经存在的 Dev Box 不一定会立刻刷新可能需要下次策略循环或重建才生效。另外计划里的时间常常以区域时区或 UTC 为基准不要凭直觉先确认基准时区再设置。如果 Dev Box 系统本身损坏比如更新后无法启动直接走“删除重建”流程就好。很多管理员舍不得删总想修复。但 Dev Box 的定位就是“可丢弃的工作站”与其花几个小时修系统不如从镜像里重建一台然后把代码从 Git 拉回来。这个思维转变反而是把 Dev Box 用好最重要的一步。我自己的经验是Dev Box 真正让人舒服的地方不是“远程桌面”三个字而是你把折腾环境的成本从每位开发者头上收走集中放到了镜像维护这一环。第一次用它建议别急着做复杂的自定义镜像和自动化先用微软预置的 Visual Studio 镜像跑两个星期把团队真正用到的依赖记下来再慢慢往自定义镜像里沉淀。踩过几次坑之后你会和我一样发现一台能随时丢弃、随时重建的开发机比什么高配笔记本都让人安心。