最近和一个同行聊到 HarmonyOS PC 应用的开发，他说文档看了几篇，框架概念也了解了个大概，但真到了要落代码的时候还是觉得无从下手——不知道从哪个文件开始写、窗口怎么建、界面怎么适配，甚至连开发环境的版本都拿不准。这个感受我特别能理解。HarmonyOS 应用开发这几年迭代非常快，手机端的资料相对多一些，但专门针对 PC 场景的系统性实战内容还是少。这篇文章我就以自己实际跑过的流程为主线，从工具链、工程骨架、UI 适配、交互能力、调试打包几个维度，把“落代码”这件事拆开讲清楚。不管你是刚从手机端迁移过来，还是第一次接触 ArkTS，照着这篇的思路走，至少能把第一个能跑的 PC 应用搭起来，后面再逐步加功能心里就有底了。
1. 环境准备与工程创建：先把工具链盘明白了
1.1 DevEco Studio 版本与 SDK 选型
做 HarmonyOS PC 应用开发，第一件事不是写代码，而是把开发环境搭对。如果你手里的 DevEco Studio 还是几个大版本之前的旧版本，我建议直接升级到新版。原因很直接：HarmonyOS 的 PC 能力支持是随着 API 版本逐渐补齐的，旧版本编辑器对窗口管理、鼠标右键、拖拽这类桌面能力的支持不完整，你在老版本上折腾半天可能只是白费功夫。
开发工具方面，现在主流使用的是 DevEco Studio 5.x 系列，对应的 SDK API 版本建议直接选 API 12 及以上。API 版本这个事我得专门提一句：不要为了“兼容性”去选旧版本。HarmonyOS 应用市场对 targetSdkVersion 有明确的审核要求，新能力也在逐步向高版本 API 收敛，选旧版本意味着你后面要处理一堆废弃接口的迁移。我见过有开发者为了省事用 API 9 写了一个应用，后来想加窗口缩放适配，发现很多 API 根本不存在，只能推倒重来。
创建工程之前，还要留意模拟器镜像的问题。HarmonyOS 的模拟器镜像在 DevEco Studio 里是可以选择下载的，默认下载的往往是手机镜像。做 PC 应用必须要额外下载 PC 或 2in1 设备的模拟器镜像，否则你连“在桌面上跑起来”这一步都过不去。镜像体积不小，下载时间取决于网络环境，建议用官方提供的镜像源，不要在第三方渠道下载。
1.2 创建 PC 工程：模板选择与设备类型配置
打开 DevEco Studio，新建工程时选择 Empty Ability 模板就够了。这个模板会生成一个最精简的 ArkTS 工程骨架，包含 entry 模块、pages/Index.ets 入口页面、module.json5 配置文件等。其他模板（比如列表模板、登录模板）在后续开发中意义不大，纯新手不建议一开始就用带大量模板代码的工程，反而干扰理解。
工程创建完之后，有一个极其容易踩坑的配置点：module.json5 里的 deviceTypes。默认情况下，新建的工程只会配置 phone 和 tablet 两类设备。如果你直接把工程跑到 PC 模拟器上，会提示安装失败或者无法识别设备。必须手动在 deviceTypes 数组中添加 "desktop" 或 "2in1"。我的习惯是直接配置成：
{ "module": { "name": "entry", "type": "entry", "deviceTypes": [ "phone", "tablet", "2in1", "desktop" ] } }这里有一个细节：不同的 DevEco Studio 版本对于“2in1”和“desktop”的支持略有差异，如果你的版本编译时提示 deviceTypes 不合法，可以在 SDK 的配置文件里查一下当前版本支持哪些设备枚举值，以官方 SDK 为准。
签名配置也是一个新手重灾区。HarmonyOS 应用调试必须签名，你用 DevEco Studio 的自动签名功能登录自己的开发者账号，工具会自动生成调试证书和 Profile 文件。注意调试证书是有有效期的，过期之后重新生成一次即可。这个机制虽然简单，但我见过不少人在安装时报错“证书无效”而找不到原因，最后发现只是证书过期了。
如果你的工程里包含 C/C++ 编写的动态库（.so 文件），还需要特别注意 CPU 架构问题。PC 模拟器和 PC 真机大多是 x86_64 架构，而手机大多是 ARM 架构。如果你的 .so 只提供了 ARM 版本，那应用跑到 PC 上会直接因为指令集不匹配而崩溃。所以工程里只要涉及 native 代码，一定要同时编出 x86_64 版本。
创建完工程之后，建议先看一眼 build-profile.json5 里的 compatibleSdkVersion 和 targetSdkVersion 字段。首次创建工程时工具会自动填一个默认值，但有时这个默认值过低，会导致你无法使用某些新特性，手动调高到当前 SDK 支持的版本即可。
2. UI 布局与窗口适配：把手机思维切换到桌面思维
2.1 窗口生命周期与属性设置
很多从手机端转过来的开发者，最容易犯的错误就是拿手机端那套“全屏、固定窗口、竖屏优先”的思路去写 PC 应用。手机应用启动就全屏，窗口尺寸基本不变，界面始终是竖屏比例，整套生命周期逻辑相对简单。但 PC 场景完全不同：窗口有默认尺寸、用户会拉伸窗口、会最小化、会同时开多个应用。
UIAbility 的生命周期在 PC 上依然适用，但你需要额外关注 windowStage 这个环节。应用启动时，系统会依次回调 onCreate、onWindowStageCreate、onForeground 等。onWindowStageCreate 是你拿到窗口对象并设置窗口属性的最佳时机，绝大多数窗口初始化工作都应该放在这里。
我在实际项目中是这么处理窗口初始化的：
import { window } from '@kit.ArkUI'; export default class EntryAbility extends UIAbility { onWindowStageCreate(windowStage: window.WindowStage): void { // 设置窗口标题 windowStage.getMainWindowSync().setWindowTitle('PC 应用示例'); // 限制窗口最小尺寸，防止 UI 被压缩到不可用状态 const mainWindow = windowStage.getMainWindowSync(); mainWindow.setWindowMinSize(800, 600); // 设置默认窗口大小 mainWindow.resize(1200, 800); // 加载页面 windowStage.loadContent('pages/Index'); } }这段代码看起来简单，但每个 API 后面都有门道。setWindowMinSize 是 PC 应用开发中不可忽视的一步。手机应用没有“窗口最小尺寸”的概念，但在 PC 上，如果用户把窗口拖得太小，你的布局就会被挤压成一团乱麻。设置一个合理的最小尺寸（比如 800x600 或 900x700），既能保住界面的基本可用性，也能避免后续处理一堆极端小窗口下的布局 bug。
setWindowLayoutFullScreen 这个 API 在手机端经常用来做沉浸式状态栏，但在 PC 端，我个人建议不要轻易开启全屏化布局。PC 上保留系统标题栏和边框可以让用户方便地拖拽、缩放窗口，体验更接近原生桌面应用。如果你确实需要“真正的全屏模式”——比如做视频播放器或演示工具——可以在运行过程中动态切换，而不是在启动时就全屏。
窗口尺寸这方面还要注意逻辑像素和物理像素的换算。代码里的数字在移动端通常直接当作 vp（虚拟像素）使用，PC 端由于存在屏幕缩放比例（比如 125%、150%），逻辑像素对应物理像素不再是 1:1。HarmonyOS 的框架会自动处理大部分换算，但你写自适应布局时会用到窗口宽度进行计算，记得获取的是窗口的宽度值而不是屏幕物理分辨率。
2.2 响应式布局的核心原则
PC 应用与手机应用最大的界面差异在于：PC 窗口宽度可以随时变化。这意味着你的 UI 必须做到“窗口变，布局跟着变”，而不是写死宽度。
HarmonyOS 提供了栅格系统，也就是 GridRow 和 GridCol 组件，这是实现响应式布局的核心工具。你可以把窗口宽度划分成若干个断点，在不同断点下使用不同的列数。官方推荐了一套断点范围：xs 是 0 到 320vp，sm 是 320 到 600vp，md 是 600 到 840vp，lg 是 840 到 1200vp，xl 是 1200 到 2000vp，xxl 是 2000vp 以上。这套断点比较符合手机、平板、PC 的典型宽度分布，但不是死规矩，你可以根据自己应用的实际情况调整。
我做一个常用的双栏布局时，代码大致是这样：
import { GridRow, GridCol } from '@kit.ArkUI'; @Entry @Component struct Index { @State currentBreakpoint: string = 'lg'; build() { GridRow({ columns: { sm: 1, lg: 2 }, gutter: { x: 12 } }) { GridCol({ span: { sm: 1, lg: 1 } }) { // 侧边栏内容 SideBar() } GridCol({ span: { sm: 1, lg: 1 } }) { // 主内容区 ContentArea() } } } }在窄窗口（sm）下，栅格只有一列，侧边栏和主内容区会上下堆叠；在宽窗口（lg）下，栅格变为两列，侧边栏和主内容区左右排布。这个方案不需要写复杂的状态判断，栅格系统内部会自动计算子项的排布位置。
需要留意的是，GridCol 的 span 配置既可以写一个具体数字，也可以写成响应式对象 { sm: 1, lg: 1 }。如果某个断点没写，系统会回退到默认值。实际开发中，我建议把栅格列数尽量控制在 1、2、3 这种小人能直接算出来的数字内，不要搞得太复杂，不然调试阶段会非常痛苦。
除了栅格系统，媒体查询也是一种常用方案。媒体查询适合处理“某个组件在宽屏下显示、窄屏下隐藏”这类需求。比如侧边栏在宽窗口下常驻，窄窗口下可以通过折叠按钮展开。这种情况用媒体查询或者监听窗口宽度变化来切换状态即可。
2.3 从手机迁移页面的细节调整
如果说栅格系统解决的是“布局怎么变”的问题，那么组件尺寸、文字大小、间距这些细节就是“界面在 PC 上是否好看”的问题。
手机界面的一个重要特征是为了触控操作，所有点击目标都做得比较大。PC 端使用鼠标操作，精度远高于手指，过大的按钮和过宽的行间距反而会让界面显得笨重。比如同样的列表项，手机上一个行高 80vp 是合理的，PC 上我一般压缩到 48 到 56vp，信息密度明显提升，视觉上也更紧凑。
文字大小也需要调整。手机端正文字号一般在 14 到 16fp 之间。PC 端的阅读距离更远，同时窗口更大，正文可以保持 14 到 16fp，但如果你的应用有统计面板、数据看板这类内容，标题字号可以适当加大到 24 到 32fp，增加层级感。不过也不要一味追求大字，PC 桌面应用的信息密度普遍比手机高，16fp 的正文配 20fp 的小标题是比较舒服的搭配。
鼠标悬停状态是 PC 界面特有的一种反馈方式。手机端没有 hover 概念，但 PC 上用户会频繁移动鼠标经过各种元素。如果你的按钮、卡片在悬停时完全没有视觉反馈，用户会感觉界面“死气沉沉”。HarmonyOS 的通用属性里提供了 hoverEffect 设置，比如：
Button('保存') .hoverEffect(HoverEffect.Shadow)这会在鼠标悬停时给按钮添加阴影效果，非常简单但体验提升明显。类似地，对于自定义组件，你也可以监听 onHover 事件，在悬停时切换背景色或状态。
焦点管理很多时候会被忽略，但键盘用户（包括无障碍用户）依赖 Tab 键在界面中移动焦点。PC 界面中可交互元素多，焦点顺序杂，建议给关键操作区域显式设置焦点行为。这一点在表单页面尤其明显，按钮按 Tab 键应当依次聚焦，而不是随机跳动。
3. 交互能力补齐：右键菜单、快捷键与拖拽
3.1 从零实现右键菜单
PC 应用和手机应用在交互模式上最大的区别之一就是右键菜单。手机上没有“右键”这个概念，但 PC 用户对右键菜单的依赖度极高。几乎任何 PC 应用里，用户都会本能地在内容区域按右键，期望看到剪切、复制、粘贴、刷新等操作。如果你的应用没有右键菜单，体验会显得非常“业余”。
HarmonyOS 的 ArkUI 框架提供了 bindContextMenu 通用属性，可以给任意组件绑定上下文菜单。我给页面里的列表项绑定右键菜单的代码长这样：
@Builder menuBuilder() { Menu() { MenuItem({ content: '复制' }) MenuItem({ content: '粘贴' }) MenuItem({ content: '全选' }) MenuItem({ content: '删除' }) } } // 在列表项组件上绑定 ListItem() { Text('内容') } .bindContextMenu(this.menuBuilder, ResponseType.RightClick)这里 ResponseType.RightClick 表示右键触发，系统还会在菜单弹出位置播放动画。实际开发中，我建议把菜单响应放在最小粒度的可操作组件上，比如列表项的根容器。如果你绑定在整个 List 上，所有列表项都会响应相同的菜单，很难实现“右键哪一项就操作哪一项”。
菜单里的菜单项可以有禁用状态：
MenuItem({ content: '删除', isEnabled: this.isDeletable })在 PC 应用中，这种细节非常常见。比如没有选中任何内容时，“复制”应该置灰；没有可撤销操作时，“撤销”应该置灰。置灰的菜单项给人一种专业软件的感觉，不做这一步会显得比较粗糙。
3.2 键盘事件与快捷键处理
PC 用户对键盘的依赖仅次于鼠标。表单里按 Enter 提交、列表里按 Delete 删除、文本区域里按 Ctrl+C 复制，这些操作在 PC 上都是“默认行为”，如果应用不支持会非常别扭。
ArkUI 的组件级 onKeyEvent 事件可以捕获按键：
.onKeyEvent((event: KeyEvent) => { if (event.type === KeyType.Down && event.keyCode === KeyCode.KEY_ENTER) { // 执行搜索 this.executeSearch(); } })注意这里不能直接用 Ctrl+C 这类组合键判断，需要手动记录当前是否有修饰键按下。我一般会维护一个状态数组，在 onKeyEvent 里同时检查 modifierKey 的键值。这个方案简单可靠，已经足够覆盖绝大多数“局部快捷键”的场景。
如果你是做工具类应用，希望应用在后台时也能响应快捷键，那就需要借助更底层的能力了。这块我建议在需求真正出现之前不要盲目实现，注册全局快捷键涉及系统级 API，复杂度高，而且如果应用要上架市场，全局快捷键行为也需要符合审核要求。先把组件内的快捷键做好，已经能覆盖 90% 的日常场景。
另外，PC 上有一个手机端不常遇到的输入场景：输入框之间的 Tab 切换。用户习惯用 Tab 从一个输入框跳到下一个输入框，这个行为在 HarmonyOS 的 Form 组件中通常是自动处理的，但如果你自己组合了多个 TextInput 组件，建议检查一下默认焦点顺序是否符合预期。
3.3 拖拽与文件拖入：不要让用户体验断层
PC 用户还有两个高频操作：拖拽文件进应用、拖拽界面元素进行排序。这两个交互在手机端几乎是不可见的，但在 PC 端属于基本功。
用 ArkUI 实现拖拽，核心是 Draggable 通用属性。下面这个示例演示了如何让一个卡片可以被拖起并响应放置：
Draggable({ builder: () => { this.dragBuilder() }, dragPreview: () => { this.previewBuilder() }, onDragStart: () => { return true }, onDragEnter: (event: DragEvent) => { event.setDragModification() }, onDragDrop: (event: DragEvent) => { // 获取拖入的数据，处理业务逻辑 } }) { CardContent() }文件拖入我实测时踩过一个坑：如果父容器设置了 clip(true) 或者裁剪相关的属性，拖拽预览可能会被裁掉一半，看起来很奇怪。解决办法是拖拽预览不要用整个组件，而是构建一个单独的预览布局，尺寸控制在合理范围。另外，拖拽预览在 PC 上是有“阴影跟随鼠标移动”效果的，拖拽过程中如果组件层级结构复杂，动画可能掉帧，可以尝试简化拖拽内容的数据量。
列表拖拽排序在 PC 应用里也很常见。实现思路是给列表项绑定拖拽事件，在 onDragDrop 中拿到源 index 和目标 index，交换数据后刷新列表。这个功能实现不难，但排序过程中的动画和占位符处理会花不少时间，建议先用最简单的方案跑通业务逻辑，再回头优化动态反馈。
还要提一下剪贴板。PC 用户在各种应用之间复制粘贴内容非常频繁，你的应用应当能正确处理来自其他应用的数据。如果是文本，直接拿系统剪贴板数据即可；如果是图片或者文件，需要处理文件路径转换。基础用法如下：
import { pasteboard } from '@kit.BasicServicesKit'; let data = pasteboard.getSystemPasteboard().getData();实际处理时要注意数据格式判断，剪贴板里可能是纯文本、HTML、富文本、图片、文件路径等多种类型，需要根据业务场景决定读取哪一种。
4. 调试运行与工程化实践：把代码跑稳跑顺
4.1 模拟器调试与真机验证
工程创建完成、界面代码写完之后，最激动人心的环节是把它跑起来。PC 模拟器调试的基本路径是：在 DevEco Studio 里选择 PC 模拟器作为部署目标，点击 Run。模拟器会启动一个真实大小的桌面窗口，你的应用就在这个窗口里运行。
模拟器和真机之间存在一个不可忽视的问题：渲染差异。我调试一个应用时遇到过背景模糊效果在模拟器里正常、真机上发虚的情况。排查了很久，最后发现是模拟器对图形特效用了一套简化逻辑，真机上的 GPU 能力更强但也会因为驱动差异产生不同表现。所以我的原则是：模拟器用于验证业务逻辑和交互流程，涉及视觉精细度的问题必须回到真机确认。
如果你的电脑硬件配置一般，模拟器运行可能会出现卡顿，尤其是页面里有大量动画和模糊效果的时候。建议在开发阶段尽量少用模糊、阴影这类高消耗特效，等性能优化阶段再统一加。
4.2 工程结构调整与组件封装
随着页面和功能增加，工程结构会迅速膨胀。我在项目里会遵循这样一个简单的模块划分原则：
- entry/src/main/ets/pages：存放页面级组件，一个页面一个文件
- entry/src/main/ets/common：存放可复用的通用 UI 组件和工具函数
- entry/src/main/ets/model：存放数据模型和接口定义
这个划分在中小型工程里足够用。如果你的应用有多个业务模块，可以进一步拆成多个 module。但是注意，多 module 工程在 HarmonyOS 里的编译和依赖管理会更复杂，对新手来说，先把单模块工程跑顺再拆分也不迟。
组件封装上有一个常见误区：为了复用而把组件拆得太细，导致页面代码必须把一堆参数传进组件，复杂度反而上升。我的建议是：同一个结构只在两三个地方出现，就不要单独抽组件；抽组件的标准不是代码行数，而是这个结构的业务逻辑是否独立、变化频率是否一致。
4.3 性能优化与状态管理要点
PC 屏幕上能同时展示的内容比手机多得多，这导致 PC 应用更容易出现列表卡顿、滚动掉帧的问题。HarmonyOS 的 ArkUI 框架中，列表类组件例如 List、Grid 都会提供懒加载能力。如果你的数据量超过几十条，务必使用懒加载或者按需渲染，而不是一次性把全部数据渲染出来。
状态管理方面，新手经常犯一个错误：把所有数据都声明成 @State，导致任何一个小变化都触发整个页面的重绘。PC 页面结构复杂，这种做法的性能影响被放得很大。更合理的做法是让状态尽量靠近使用它的组件：
- 组件内部的状态用 @State 管理
- 父子组件间的数据共享用 @Prop 和 @Link
- 跨组件甚至跨页面的复杂状态用 @Observed 和 @ObjectLink 管理
我见过最典型的性能问题场景：一个页面顶部有搜索框，用户在搜索框里输入一个字符，整个页面所有列表项都刷新了一遍。原因是搜索关键字定义在了页面级 @State，而列表项的渲染逻辑依赖了页面级状态。优化思路很简单，把搜索关键字下放到搜索框子组件内部管理，列表数据的过滤结果由页面统一计算，再传给列表。改动不大，体感差别很大。
4.4 常见崩溃与界面问题排查
开发 HarmonyOS 应用，崩溃定位比常规移动开发更依赖日志工具。我的常用排查路径是：
- 应用闪退时，先连上 hdc，拉取系统日志。在 DevEco Studio 的 Terminal 里执行：
hdc shell hilog | grep -E "FATAL|Error"- 如果日志太长，可以只查最近一次崩溃的堆栈：
hdc shell "hilog -x | grep -A 30 'FATAL EXCEPTION'"惯用命令不建议死记，DevEco Studio 的 Log 面板里可以直接过滤关键字。重点看 FATAL EXCEPTION 后面的堆栈信息，里面的文件路径和行号可以直接定位到代码位置。
UI 界面问题里最常见的三类是：页面白屏、布局错乱、图片不显示。页面白屏多数情况是页面入口路径配置错误，检查 main_pages.json 或者路由表有没有注册对应页面。布局错乱通常是响应式适配没做好，把窗口宽度拉窄看哪里被挤压变形。图片不显示先检查图片资源是否放进了 media 目录，其次检查图片路径是否是相对路径，绝对路径在打包后大概率失效。
还有一类很隐蔽的问题：应用在模拟器上正常，但打成 hap 包安装到真机上崩溃。这个问题大概率跟签名或者权限配置有关，检查 Profile 文件是否覆盖了真机设备，以及 manifest 里声明的权限是否都被签名文件允许。
5. 打造 PC 专属体验：从功能完整到体验自然
5.1 窗口管理的高级用法
如果应用做到了这个阶段，说明核心功能已经可以正常工作了。但要把应用从“能在 PC 上跑”升级到“像 PC 上的原生应用”，还需要关注一些更深层的细节。
窗口管理是 PC 应用区别于手机应用的一个重要领域。除了设置初始尺寸和最小尺寸，你还可以控制窗口的缩放行为。比如用 setWindowAspectRatio 设置窗口比例，可以让窗口始终保持 16:9 之类的固定比例。这个能力特别适合视频播放器、图片浏览器这类应用。如果你的应用是工具类，不建议限制比例，用户往往会根据自己的屏幕尺寸自由调整窗口形状。
窗口之间的协作也是 PC 应用特有的需求。HarmonyOS 支持在一个应用内创建多个窗口，每个窗口加载不同的页面。在做文档编辑器时，我尝试过用多窗口方案：主窗口显示文档列表，双击文档后在新窗口打开编辑器。这个体验很接近桌面原生应用。多窗口的代码量会明显增加，要处理好窗口之间的数据同步问题和窗口关闭时的资源释放，但回报也是实实在在的，应用的专业感会提升一大截。
5.2 多显示器与分辨率适配
PC 用户使用多显示器的比例比想象中高，特别是办公场景。你的窗口可能在主显示器上打开，但用户会把它拖到副显示器上。不同显示器的分辨率和缩放比例可能完全不同，代码里如果使用了硬编码的像素值，在缩放比例不同的屏幕上就会出现文字模糊、控件错位。
HarmonyOS 的 ArkUI 布局默认使用 vp 做单位，系统会自动处理大部分缩放问题。但如果你自己拼接了 PixelMap 或者 Canvas 绘制，就得特别注意单位换算。在 Canvas 上绘制图形时，需要把 vp 转换成 px，否则在缩放比例不为 100% 的屏幕上，绘制结果会明显偏移。
5.3 用日志和错误上报固化质量
应用上线前，建议在工程里接入统一的日志管理。我的做法是封装一个简单的日志工具类：
export class Logger { static info(tag: string, message: string): void { console.info(`[${tag}] ${message}`); } static error(tag: string, message: string): void { console.error(`[${tag}] ${message}`); } }然后在代码统一调用 Logger.info 和 Logger.error。这套封装看起来简单，但实际价值不小：一个是日志格式统一，后续用 grep 过滤时非常方便；另一个是如果将来要接云端日志上报，只需要改这一个类。
线上崩溃数据是最宝贵的质量反馈。HarmonyOS 提供了一些系统级的能力来捕获异常，不过具体接入方式和 API 版本强相关，建议开发时直接在官方文档查当前 SDK 版本的“崩溃日志采集”相关说明。
6. 写在最后的实践心得
回顾整个流程，从环境搭建到窗口初始化，再到响应式布局、右键菜单、拖拽交互、调试打包，每一步踩下来，我最深的体会是：HarmonyOS PC 应用开发并不神秘，但它一定不是“把手机应用放大”这么简单。
我刚开始接触时，犯过一个很典型的错误：把手机端页面跑在 PC 模拟器上，结果按钮巨大、列表空荡荡，整个界面一眼望去不像桌面应用。后来我逐步意识到，PC 场景的核心价值是信息密度和多任务效率。同样的一个列表页面，手机上可能一屏只展示七八条，PC 上应该展示二三十条；手机上只能单栏操作，PC 上应该充分利用宽度做侧边栏和内容区。
另一个经验是：不要追求一次到位。先做一个最小可用的闭环——一个列表加一个详情页，绑定上右键菜单和基本的窗口缩放适配——先把这个闭环跑顺，验证用户真的在 PC 上能舒服地使用，再逐步增加拖拽排序、多窗口、快捷键这些进阶能力。过早铺开功能往往会导致每一块都做得不到位，排查问题时还容易互相干扰。
最后提一个非常实用的小建议：开发 PC 应用时，把模拟器窗口拖动到你日常开发使用屏幕的大小，再根据这个实际尺寸调整布局断点和组件尺寸。不要只看预览器里的默认效果，因为预览器默认尺寸通常是一个手机的竖屏窗口，和 PC 桌面体验差别非常大。把窗口拉到你真正会用的大小去调试，才能确保你在交付前看到的，就是用户体验到的。
