VSCode代码片段省时关键在于定义高频、有上下文约束的模板；如logf片段用$TM_FILENAME_BASE标识文件源，$1/$2控制光标，带description便于识别。
VSCode 的代码片段（Snippets）本身不“节省时间”，真正省时间的是你提前把重复模式固化成可触发的模板——关键不在功能有多炫，而在你是否定义了真正高频、有上下文约束的片段。
怎么写一个能用的 console.log 片段而不是玩具
很多人写完 "log": { "prefix": "log", "body": ["console.log($1);"] } 就停了，但实际开发中几乎不用裸 console.log。真正省时间的写法要带作用域标识和自动选中：
-
$TM_FILENAME_BASE插入当前文件名（不含后缀），避免日志混在一起看不出来源 -
$1和$0控制光标位置：先填变量名，回车后直接跳到括号里输内容 - 加
"description": "log with filename prefix"，触发时能快速识别意图
{
"logf": {
"prefix": "logf",
"body": ["console.log('[${TM_FILENAME_BASE}] $1', $2);"],
"description": "log with filename prefix"
}
}
为什么 for 片段在 TypeScript 里容易出错
TypeScript 中直接展开 for (let i = 0; i 有两处隐患：
- 没声明数组类型，
${1:arr}可能是any[]或undefined，TS 检查会报错 - 没用
for...of或forEach，现代 TS 更倾向类型安全的遍历方式 - 更稳妥的片段应默认绑定类型提示，比如用
${1:items}: ${2:Array<string>}
真正省时间的不是“写得快”，而是“写完不修类型错误”。
全局片段 vs 工作区片段：什么时候该用哪个
全局片段（放在 snippets/javascript.json）适合语言通用结构，比如 try/catch、Promise.resolve；工作区片段（.vscode/snippets/xxx.json）才解决真实痛点：
- 项目特定 hook 调用，如
useApiError需要固定依赖数组和返回结构 - 内部 SDK 初始化模板，含环境判断和 fallback 处理
- CI/CD 脚本中重复的
if [ -z "$VAR" ]; then ... fi结构
别把所有片段都塞进全局——越具体，触发越精准，误触越少。
片段不能替代重构，但能暴露设计问题
如果你发现自己频繁为同一类组件写几乎一样的 useEffect + useState + cleanup 片段，这不是片段用得好，是该抽自定义 Hook 了。片段是胶水，不是架构。它最擅长处理“已知结构+局部变量替换”，一旦开始复制粘贴逻辑分支或条件嵌套，就该停手去改代码组织方式了。
