需插件而非脚本：适合高频、跨文件、需UI交互或上下文感知的集成；单次文本替换类任务用脚本更优。插件核心价值在于读取编辑器状态并精准注入代码。
生成系统集成逻辑前，先确认你真需要插件而不是脚本
VSCode 插件不是万能胶——它适合高频、跨文件、需 UI 交互或上下文感知的集成任务（比如一键生成对接飞书/钉钉/企微的 Webhook 处理函数），但如果是单次、固定路径、纯文本替换类操作（如批量改 API 基地址），用 Node.js 脚本或 sed/awk 更快更可控。插件真正的价值在于：能读取当前编辑器状态（光标位置、选中文本、当前语言、workspaceRoot）、触发命令后自动写入正确位置、并支持后续调试和 Git 追踪。
用 Webview + VS Code API 实现动态集成模板注入
多数“系统集成逻辑”本质是模板填充：比如生成一个调用腾讯云 COS 的上传函数，需填入 SecretId、SecretKey、Bucket 和回调路径。硬编码在插件里会泄露密钥，也不灵活。推荐方案是用 vscode.window.createWebviewPanel 拉起一个轻量表单页：
- 表单字段对应集成参数（可设为必填/选填，用
required属性校验） - 提交后，插件通过
vscode.window.activeTextEditor?.insertSnippet把生成的代码插入到光标处，而非直接写文件——避免覆盖已有逻辑 - 模板本身存为
templates/cos-upload.ts等 JSON 或 Handlebars 文件，方便团队维护，不需重编译插件 - 注意：Webview 中不能直接访问
process.env，敏感字段（如密钥）必须由用户手动输入或从 VS Code 的secretsAPI 获取（需声明secrets权限）
避免在 extension.ts 里硬写业务逻辑
把具体集成逻辑（如“生成飞书机器人消息发送函数”）写死在 extension.ts 里，会导致每次新增系统都要发新版本。更可持续的做法是分层：
- 主插件只负责调度：监听命令 → 加载对应模板 → 填充参数 → 注入代码
- 每个系统集成封装成独立模块，例如
src/integrations/feishu.ts导出getTemplate()和validateInputs() - 模板数据结构统一为：
{ snippet: string, requiredFields: string[], description: string }，便于前端表单自动渲染 - 这样新增一个“对接 Notion 的页面创建逻辑”，只需加一个
notion.ts文件，无需动核心逻辑
调试时别忽略 workspace 级别的 context 差异
本地测试一切正常，一到同事机器上就报错？大概率是没处理好 workspace 上下文。常见坑：
-
vscode.workspace.workspaceFolders可能为null（没打开文件夹），直接调用.map()会崩，得先判空 - 不同项目可能用不同包管理器（
pnpmvsyarn），生成的依赖安装命令不能写死，要用vscode.workspace.getConfiguration('npm').get('packageManager')动态读取 - 某些集成逻辑需读取项目根目录下的配置文件（如
env.json或integrations.config.js），但用户可能没放，得提供 fallback 提示而非静默失败
真正卡住人的往往不是语法，而是这些看似边缘、却决定能否落地的上下文细节。
