vscode.window.createtexteditordecorationtype 不能直接写函数装饰器，它是用于设置文本高亮样式的编辑器api，与typescript/python的@decorator语法糖无关；混淆二者会导致命令注册失败或插件启动报错。
vscode.window.createTextEditorDecorationType 能不能直接写函数装饰器
不能。VSCode 的 createTextEditorDecorationType 和 TypeScript/Python 里的 @decorator 完全无关——前者是编辑器 API，用于给代码范围加高亮、图标等视觉标记；后者是语言语法糖，用于修饰类、方法或属性的元行为。
混淆这两者会导致：注册命令失败、装饰器不生效、甚至插件启动报错 TypeError: Cannot read property 'registerCommand' of undefined。
-
createTextEditorDecorationType返回的是TextEditorDecorationType实例，只接受样式对象（如{ backgroundColor: '#ff0' }），不接受函数 - 想在插件里“写函数装饰器”，实际是指用 TypeScript 5.4+ 的标准装饰器语法自动注册命令、监听事件等，比如
@command('my.ext.hello') - VSCode 自身源码大量使用装饰器（如
@memoize、@observable），但那是内部实现，插件开发者需自行实现或借助库（如vscode-decorators）
如何用 TypeScript 5.4 装饰器自动注册命令
核心是手动实现一个装饰器工厂函数，把方法绑定到 vscode.commands.registerCommand，并确保 context.subscriptions 正确管理生命周期。
常见错误是没传入 ExtensionContext，导致 context.subscriptions.push() 报错；或者装饰器执行时机早于 activate，造成 vscode 模块未就绪。
- 装饰器必须在
activate函数内、且vscode可用之后才可应用（不能直接装饰类顶层方法） - 推荐写法：先定义装饰器函数，再在
activate中对实例方法调用装饰器，或用类工厂模式延迟绑定 - 示例中
@command必须接收完整命令 ID 字符串，不能是变量或模板字符串（否则热重载时命令名会变，导致旧订阅残留） - TypeScript 5.4 启用
experimentalDecorators和emitDecoratorMetadata才能正确生成元数据
setDecorations 为什么只对当前 editor 生效
editor.setDecorations 是实例方法，只作用于传入的那个 TextEditor 对象。它不会跨文档、不会影响其他 tab，更不会自动同步到新打开的文件。
如果你希望所有 JS 文件都高亮某个模式（比如 async 函数），就必须监听 onDidChangeActiveTextEditor 和 onDidChangeTextDocument，并在每次切换或编辑后重新计算 Range 并调用 setDecorations。
- 漏掉
onDidChangeActiveTextEditor监听，会导致切换文件后装饰消失，用户以为“失效了” - 直接对
vscode.window.visibleTextEditors全量调用setDecorations会触发大量重绘，卡顿明显 - 每个
TextEditorDecorationType应复用，不要每次创建新实例（否则内存泄漏 + 样式冲突） - 装饰范围
Range必须基于当前文档内容实时计算，不能缓存旧的Position（编辑后行列偏移会变）
装饰器性能瓶颈常被忽略的三个点
不是装饰器本身慢，而是配套逻辑没做收敛。高频编辑下，每敲一个字符都触发重分析，很容易拖垮编辑器。
- 正则匹配没加
g或multiline标志，导致只匹配第一行，后续装饰“看起来没生效” - AST 分析（如用
typescript模块解析）没做防抖，onDidChangeTextDocument事件每秒可能触发 10+ 次，每次都全量 parse - 没清理旧装饰：调用
setDecorations传空数组[]才能清除，传undefined或不调用，旧装饰会一直挂着
真正难的不是写出来，是在不同语言文档、不同编辑状态、不同用户操作节奏下，让装饰稳定、轻量、可预测。别急着堆功能，先跑通单文件 + 单次触发的最小闭环。
