VS Code 无法原生命生小程序骨架，因其仅为编辑器而非构建工具，所有生成操作均依赖外部 CLI（如 @tarojs/cli、miniapp-cli）执行；微信无官方 CLI，支付宝 CLI 不兼容微信，双端结构差异大，无法统一模板。
VS Code 本身不提供小程序骨架生成能力，所谓“快速生成”实际依赖第三方 CLI 工具或插件配合手动初始化，且微信与支付宝的项目结构、配置项、生命周期函数差异大，无法靠一个命令同时兼容两端。
为什么不能用 VS Code 原生命令生成小程序骨架
VS Code 是编辑器，不是构建工具。它没有内置 create-miniprogram 或 init-alipay-project 这类命令。所有“生成骨架”动作，本质是调用外部 CLI（如 @tarojs/cli、miniprogram-cli、支付宝官方 miniapp-cli）在终端执行，VS Code 只负责打开终端或触发任务。
- 微信小程序官方未提供命令行初始化工具，必须手动创建
app.js、app.json、project.config.json等文件，或依赖第三方框架（如 Taro、UniApp）生成 - 支付宝小程序虽有
miniapp-cli，但需单独安装，且生成的是纯支付宝结构，不含微信适配层 - 试图用同一套模板同时满足微信和支付宝，会导致
app.json与mini.project.json冲突、API 调用路径错乱、自定义组件注册方式不一致等问题
真正可行的“双端骨架”生成路径
想在 VS Code 中快速起手双端项目，唯一稳健做法是：用跨平台框架 CLI 初始化，再通过 Antmove 插件做定向转换，而非追求“一步生成两个完整骨架”。
- 推荐使用
@tarojs/cli：运行taro init myapp，选择「微信小程序 + 支付宝小程序」双端支持，它会生成统一源码 + 各端独立构建配置 - 避免直接用
npm init或空文件夹手动搭骨架——缺少基础构建链路（如babel插件处理wx.→my.）、source map 配置、类型声明引入，后续调试会卡在断点不命中、API 报undefined - 若坚持原生开发，可先用微信开发者工具新建项目导出代码，再用 VS Code 打开；支付宝端则必须另起一个
mini.project.json并补全app.js中的App()入口，二者不可复用同一份app.js文件
Antmove 插件能帮你省掉哪些手动操作
Antmove 不是骨架生成器，而是转换器。它能在已有微信小程序基础上，批量重写路径、API、事件绑定和配置文件，让项目“看起来像”支付宝小程序——但不会自动补全支付宝特有的 ap 前缀 API 或云函数配置。
- 自动把
app.json转成mini.project.json，并映射页面路径、窗口样式字段（如"navigationStyle": "custom"→"titleBar": "transparent"） - 把
WXML中bindtap改为onTap，wx:if改为a:if，但不会处理wx:for-item和a:for-item的变量作用域差异 - 将
WXSS中的flex-direction: column类声明保留，但不修正支付宝不支持的伪类（如::after在部分旧版支付宝容器中失效） - 关键坑点：
antmove.config.js中的input必须指向真实存在的微信项目根目录（如./miniprogram），不能是空文件夹；否则插件静默跳过，无报错也不生成文件
配置双端共存时最容易被忽略的细节
即使用了 Taro 或 Antmove，微信与支付宝的运行时行为仍存在底层差异，这些不会在骨架生成阶段暴露，但会在首次真机调试时突然报错。
- 微信的
page.json页面级配置，在支付宝中对应的是mini.project.json里的pages数组内嵌对象，字段名不同（如"enablePullDownRefresh"→"pullToRefresh"），漏改会导致下拉刷新失效 - 支付宝不支持
Component构造器的relations字段，若微信端用了自定义组件通信，转换后需手动降级为事件总线或全局状态管理 - 所有网络请求必须显式判断环境：
if (my.canIUse && !wx.canIUse) { /* 支付宝 */ }，不能只靠转换插件加my.request—— 因为有些场景下my对象可能未加载完成 - VS Code 中若同时打开微信和支付宝两个子文件夹，务必为它们分别配置
jsconfig.json，否则 TypeScript 类型提示会交叉污染（比如在支付宝 JS 里误提示wx.login可用）
