Edit哦，说的是 HBuilderX 啊，理解了，太尬了。我没记错的话，HBuilderX 好像是魔改的 VSCode？内置了一些扩展&优化。其实这些扩展和优化，在 VSCode 的插件市场也能找到对应的替代品。我的话如果不是开发 uni-app 的项目，可能都不会使用 HBX，现在也只是当成一个启动器用（懒得改造成CLI构建）如果你只是开发 uni-app 的项目，用 HBX 是没问题的，如果有考虑开发其他类型的项目，的话还是建议使用 VSC 或者 WebStorm 的。毕竟不是一个专业做编辑器或者IDE的公司。整体来说是会快一点点，总的来说就是一次编写到处 Debug。 就是怕 Debug 的时间超出开发周期。简单的需求确实会快很多，因为编译完成之后稍微调试一下就能跑了，那么上架到对应平台就行，那么确实很好用。如果需求比较复杂或者需要上的平台很多，那么就大概率会出现各种兼容问题。调试&定位问题 + 解决问题的时间就会特别长，然后发现A端没问题了，B端又出现问题，B端好了，C端又出现其他的问题了。最后写一堆 #ifdef 的判断。还有很大可能是你依赖的某一个库/插件它不支持你需要的平台，然后推倒重来，再找一个新的库去实现需求。中间花费的时间可能你多个平台各写一套的整体工时差不多了。
极客观点
项目管理
HarmonyOS
Edit
哦，说的是
HBuilderX啊，理解了，太尬了。我没记错的话，
HBuilderX好像是魔改的VSCode？内置了一些扩展&优化。其实这些扩展和优化，在
VSCode的插件市场也能找到对应的替代品。我的话如果不是开发
uni-app的项目，可能都不会使用HBX，现在也只是当成一个启动器用（懒得改造成CLI构建）如果你只是开发
uni-app的项目，用HBX是没问题的，如果有考虑开发其他类型的项目，的话还是建议使用VSC或者WebStorm的。毕竟不是一个专业做编辑器或者IDE的公司。整体来说是会快一点点，总的来说就是一次编写到处
Debug。 就是怕Debug的时间超出开发周期。简单的需求确实会快很多，因为编译完成之后稍微调试一下就能跑了，那么上架到对应平台就行，那么确实很好用。
如果需求比较复杂或者需要上的平台很多，那么就大概率会出现各种兼容问题。调试&定位问题 + 解决问题的时间就会特别长，然后发现A端没问题了，B端又出现问题，B端好了，C端又出现其他的问题了。最后写一堆
#ifdef的判断。还有很大可能是你依赖的某一个库/插件它不支持你需要的平台，然后推倒重来，再找一个新的库去实现需求。中间花费的时间可能你多个平台各写一套的整体工时差不多了。