企业官网建设流程全解析

做这个全局快捷键文本输入工具的想法，最早源于一次特别没出息的加班。那天我在后台系统里把同一段售后话术复制粘贴了三十多次，复制、切换窗口、粘贴、发送，再切回来，一晚上下来手比脑子累。后来我不停反问自己：字是一样的字，话说得也一样，为什么就要一遍遍重复敲键盘？于是我从那周开始盘需求、写原型，最后做成了一个稳定的全局快捷键文本输入工具，一直用到现在。

这个工具的使用方式很简单：按一下全局热键，当前屏幕上会弹出一个小候选窗，输入几个字母就能过滤出预设好的句子或模板，回车后文字会直接插入你光标所在的地方，期间不用切窗口、不用碰鼠标、更不用重新复制。它解决的就是重复输入问题，把那些固定回复、测试账号、常用地址、代码模板统统变成“两三个键”的事情。这篇文章不是讲大道理的，我会把从需求到实现的关键取舍、底层原理、代码逻辑和真实踩过的坑都记录下来，适合被重复输入折磨的普通用户，也适合想自己动手写桌面小工具的开发者。

1. 重复输入并不是小事：一个工具作者的真实痛点清单

1.1 那些每天几十次的“复制粘贴”，到底浪费了多少时间

我一开始也以为重复输入只是文案类工作才有的烦恼，后来简单统计了自己一周之内反复输入的内容，发现远不止话术模板，比如测试邮箱、收货地址、公司抬头、工单编号、标准工时描述、常用 SQL 查询条件、米玛字符频繁的组合。这些事情看起来每次只有几秒钟，但一天下来可能占用超过 40 分钟。更让人难受的不是时间本身，而是注意力被反复打断，本来在写的思路被一次次“去找源文本、复制、粘贴”割得七零八落。

我当时给自己拍了个脑残需求：让重复输入从“复制粘贴三步”变成“按热键、输入两三个字母、回车”三步，而且要在任意窗口里都能生效。这里的关键词是“任意窗口”，包括老的记事本、现代编辑器、浏览器输入框，甚至是一些不做无障碍支持、不响应标准快捷键的内嵌控件。普通复制粘贴天然在这类场景里有效，但我想做的工具必须比它更省事。

1.2 现成方案为什么都不够顺手：输入法短语、剪贴板增强、脚本工具各有各的短板

在决定自己动手之前，我当然试过市面上的替代方案。第一类是输入法自带的自定义短语，它的优点是系统级接入，打字过程里就能触发。但问题也很明显：短语数量有限，管理界面普遍难用，而且触发方式依赖输入法状态，一旦切到英文输入法，整套短语就失效了。对于我的场景——很多模板本身就带英文代码、中英混排，还要在不同输入法状态下切换——输入法方案根本没法兜底。

第二类是剪贴板增强工具。这类工具适合“多次粘贴同一内容”，因为它的基本逻辑还是复制、调出历史面板、点击粘贴，本质上还是三步操作，并没有缩短太多。我更想要的是“按一个快捷键直接输入”，而不是再选择一次历史项。而且剪贴板增强工具在反复复制粘贴时会污染剪贴板，剪贴板里经常留下敏感或无关数据，这对我来说很不友好。

第三类是各种热键脚本工具。这类工具的自动化能力强，但对文本输入的支持反而比较弱。有的脚本炉火纯青地模拟按键、延时、循环，但遇到中文内容、特殊编码、RichEdit 控件时，经常出现乱码或插入到错误的输入框。另一部分热键工具则过于强调“键盘映射”，把某个键位改成一段宏，却没考虑用户需要一个交互式的候选列表。我需要的是一个能“根据关键字搜索句子、然后直接输入文本”的交互工具，而不是一条固定宏。

1.3 我给自己定的四条硬指标，后来成了所有技术选型的准绳

自己动手的好处是能把需求收敛到不能再清楚。我软磨硬泡给自己规定了四条硬指标。

第一，唤出延迟必须控制在极低范围内，按下热键到弹窗出现，整体要在一眨眼之间完成，不能有肉眼可见的转圈或加载。第二，文本插入不能破坏目标窗口的原有状态，包括剪贴板、输入法状态、当前窗口的焦点。第三，配置必须纯文本化，方便备份和同步，而且要支持分组和标签，避免词库一多就乱成一团。第四，资源占用要克制，作为一个长期驻留后台的工具，内存稳定在几十 MB 级别，不能像个常驻游戏一样耗电烧 CPU。

这些硬指标看起来很朴素，但后来实践里每一个都逼出了不少技术细节。尤其是第二点，真正做的时候才发现“不破坏状态”这四个字有多难。全局热键怎么注册、钩子怎么挂、文本用什么方式送进目标窗口、候选窗怎么才能不抢焦点，都是围绕它们展开的。

2. 全局热键怎么做到“任一窗口都能响应”：热键注册与低级键盘钩子

2.1 为什么先用 WH_KEYBOARD_LL 而不是更简单的 RegisterHotKey

提到全局热键，很多有经验的朋友第一反应是 RegisterHotKey。这个 API 确实简单，把要监听的修饰键和按键传进去，系统会在对应组合键按下时往你的消息队列塞一个 WM_HOTKEY 消息，不需要你管理复杂的事件流。但它有两个绕不开的局限：第一，它监听的是“热键事件”，而不是“按键事件”，你没法做基于按下顺序、连续按键这类更贴近日常输入习惯的触发；第二，WM_HOTKEY 消息必须由一个消息循环接收，如果你的程序里没有正确的消息泵，回调根本不会执行。

我想要的效果不只是响应一个固定热键，还希望候选窗出现之后，能够在尽量不夺取焦点的前提下完成“继续输入字母过滤、上下键选择、回车确认”这一整套交互。这种情况下，RegisterHotKey 只是一个触发点，到了交互阶段，普通控件焦点问题会立刻变成一个巨大的坑。所以我在主触发链路里选了低级键盘钩子 WH_KEYBOARD_LL。

打个比方：RegisterHotKey 相当于你打电话给系统说“这个号码我来接”，系统把电话转给你；低级键盘钩子则相当于你直接坐在总机旁边，能看到每一通电话的进出，还能在转接前决定要不要拦下来自己处理。WH_KEYBOARD_LL 会在按键消息派发到目标窗口之前，先经过我注册的钩子过程，于是我可以先判断“这组按键是我的触发键吗”，是的话就直接拦住，绝不让它再继续传到当前窗口；不是的话就原样放行，保证正常打字不受影响。

2.2 钩子回调与消息循环的最小实现：别在回调里做重活

低级键盘钩子在 C# 里可以通过 P/Invoke 方式调用，关键代码量并不大。核心结构是下面这段样子的：

private delegate IntPtr LowLevelKeyboardProc(int nCode, IntPtr wParam, IntPtr lParam); [DllImport("user32.dll")] private static extern IntPtr SetWindowsHookEx(int idHook, LowLevelKeyboardProc lpfn, IntPtr hMod, uint dwThreadId); [DllImport("user32.dll")] private static extern bool UnhookWindowsHookEx(IntPtr hhk); private IntPtr HookCallback(int nCode, IntPtr wParam, IntPtr lParam) { if (nCode >= 0 && wParam == (IntPtr)WM_KEYDOWN) { var info = Marshal.PtrToStructure<KBDLLHOOKSTRUCT>(lParam); // 在这里判断组合键，匹配到之后触发候选窗 if (CheckTrigger(info.vkCode)) { return (IntPtr)1; // 拦截消息 } } return CallNextHookEx(_hook, nCode, wParam, lParam); }

这段代码里最容易翻车的不是判断逻辑本身，而是钩子回调里绝对不能做重活。低级键盘钩子跑在系统派发输入的上下文中，如果你在回调里做文件读取、网络请求、复杂的字符串正则、UI 弹窗，用户的整个键盘输入都会明显卡顿，严重时系统会直接把钩子回调移除以避免拖垮全局。我的处理是：回调只做按键匹配和标志位触发，真正打开候选窗、加载配置、重建列表这些操作全部丢给主线程的消息循环去排队执行。

这里也顺带解释了为什么程序里必须有一个正确的消息循环。钩子的回调能够被触发，依赖的是当前线程在处理系统消息；如果你写的是控制台程序并且直接 Thread.Sleep 阻塞线程，钩子几乎是收不到事件的。我最后采用的结构是标准的消息循环线程加上一个隐藏窗口，用隐藏窗口接收 WM_HOTKEY 等其他系统消息，钩子回调则通过线程安全队列/事件来通知界面层。

2.3 隐藏窗口存在的意义，以及多开冲突怎么处理

很多桌面工具的功能其实不需要可见窗口，但出于消息循环和系统事件接收的需要，依然要创建一个不显示的窗口。这个隐藏窗口在 .NET 里可以用 NativeWindow 挂一个自定义消息处理，也可以在 WPF 里借助 HwndSource 实现。它的作用主要有两个：一是给消息循环一个稳定的宿主，二是接收系统广播消息，比如热键冲突、会话切换、电源事件等。没有它，纯靠线程消息泵会少掉很多系统层面的感知能力。

还有一个非常实际的问题是多开。如果用户不小心启动了第二个实例，两个实例同时挂低级键盘钩子，会导致按键被重复判断，可能触发两个候选窗，把整个输入流程搞乱。我给程序加了命名互斥体做单例保护，第二个实例启动时直接检测到已有实例，然后把自己退出，同时可以带参数通知已经运行的实例去重新加载配置。这类细节平时看不见，但真的漏掉一次用起来就是灾难。

3. 把文本送进目标窗口：Unicode 输入的三种方案和最终取舍

3.1 方案A：SendInput 模拟按键，ASCII 场景下最快但有隐形边界

弹出候选窗只是第一步，更核心的问题是怎么把选中的文字“塞进”当前光标所在的位置。最先想到的方案是 SendInput。SendInput 可以模拟键盘按键，比如给目标窗口发送一串字母键和符号键，效果等同于用户自己按了键盘。

对纯英文、数字、常见符号这类 ASCII 范围的内容，用它非常快，而且不依赖剪贴板，对目标窗口也没太多侵入。我早期版本里有相当一部分代码片段走的就是这条路，效果也确实利落。但问题很快就浮现了：一旦内容包含中文，SendInput 就没有办法直接“模拟中文按键”，因为中文字符在物理键盘上并不存在。你想让用户敲拼音、再选字，这在自动化脚本里要么依赖输入法 API，要么被迫走剪贴板，复杂度立刻上来了。

另外 SendInput 还要注意键盘布局。如果你的系统当前是法语或俄语布局，模拟按字母键时打出的字符可能跟你预期完全不同。我后来只有在“整段内容都是纯 ASCII”这个明确条件下才走这条路，其他场景一律交给下一套方案。

3.2 方案B：剪贴板加 Ctrl+V，我最后选择的主力方案，附恢复剪贴板的经典时序问题

既然很多内容都有中文，最稳妥的办法反而很朴素：程序先把文本放到系统剪贴板，然后模拟一次 Ctrl+V，让目标窗口自己完成粘贴。这套方案的最大优势是“内容编码由系统剪贴板承担”，中文、换行、特殊符号都能原样交给目标应用，几乎不会出现乱码。

但它的代价同样明显：你动了用户自己的剪贴板。我曾经偷懒直接不清剪贴板，结果用户那边原先复制的文本被我覆盖了，下一单工时记录直接粘贴出错误内容，后来我就老老实实加了一套保存和恢复机制。核心逻辑是这样的：按下触发键进入插入流程时，先把当前剪贴板对象保存到内存变量里，设置新文本，模拟 Ctrl+V，然后等 300 到 500 毫秒让目标窗口完成读取，再把剪贴板恢复成原来的对象。这里有个真实的时序陷阱：如果你粘贴完立刻恢复剪贴板，部分编辑器可能还没来得及读取，结果什么都没插进去。延时太小会失败，延时太大又会明显拖慢连续插入的节奏，最后我取了 400 毫秒这个折中值。

还有一点值得注意：剪贴板里的原始对象如果是从某个应用复制出来的复杂对象，保存和恢复时不能只取文本，否则粘贴到其他表格里的就不再是原来的富文本或表格数据。我自己用的恢复策略是比较保守的，保存整个 DataObject 对象，恢复时用 SetDataObject 塞回去，虽然偶尔遇到占用锁，但整体可靠。

3.3 方案C：WM_CHAR 发 Unicode 消息，绕过输入法的思路，兼容性却很挑剔

第三种方案是直接向目标窗口发送 WM_CHAR 消息，逐个字符把 Unicode 内容“发”进去。它的好处非常明显：不碰剪贴板、不依赖输入法、不需要模拟 Ctrl+V，逻辑上跟一种纯消息注入没有区别。

但我在真实开发里放弃把它作为主力是有原因的。现代应用对 WM_CHAR 的响应并不统一，尤其是一些基于浏览器内核的界面、自绘控件、游戏内输入框，它们可能压根不处理传统的字符消息，导致字符静默丢失。即便是一些桌面端成熟编辑器，WM_CHAR 发送进去时也要看当前光标状态跟消息投递位置是否匹配，稍有偏差就可能插到错误位置。它更适合作为剪贴板方案的降级补充，比如当检测到目标应用对 Ctrl+V 无响应、或者系统剪贴板被异常锁定时，再尝试用 WM_CHAR 手动逐字输入。

3.4 三种方案的混用原则：按内容类型自动路由

在真实版本里，我最终实现的是一套混合路由逻辑：纯 ASCII 短片段优先走 SendInput，其他内容走剪贴板加 Ctrl+V，只有检测到剪贴板访问异常或目标控件不支持粘贴时，才退回到 WM_CHAR。这个选型不是为了炫技，而是为了把每种方案的优势都利用上，同时让各自的坑不集中爆发。

下面这张表是我当时对比三种方案的核心结论，也是后来调整逻辑的依据：

听起来简单，但实际还要处理一个细节：插入文本之后，有些编辑器会保留一个“撤销”步骤，用户按 Ctrl+Z 可以撤销整个粘贴；另一些编辑器则会逐字符注册撤销步骤。为了获得一致的撤销体验，我在剪贴板插入后会给目标窗口发送一小段空操作消息让编辑器合并动作。这个属于体验优化，不解决也不影响正确性，但不做的话用户会明显感觉到“粘贴行为很怪”。

4. 候选弹窗的细节之争：如何做到“不抢焦点”还能顺畅交互

4.1 WS_EX_NOACTIVATE 与画窗位置：弹窗不是普通的弹窗

候选弹窗很容易被做成一个普通窗口，但那样会立刻发生一个非常令人沮丧的问题：用户正在某个文档里打字，热键一按，弹窗激活了自己，当前窗口的焦点和光标全部丢失，用户的输入节奏直接被打断。你写一个文本输入工具的初衷是为了让流程更顺滑，而不是每次唤起都让用户重新回到刚才的位置点一下鼠标。

解决办法是给候选窗设置 WS_EX_NOACTIVATE 扩展样式，同时配合 WS_EX_TOOLWINDOW 让它不显示在任务栏上。窗口风格设置之后，弹窗被显示时不会主动夺取系统焦点，用户当前正在输入的那个窗口始终保持焦点状态。这里有一个很容易忽略的后果：既然窗口不激活，那普通文本框控件里的键盘事件就未必能收到所有按键，因为系统会把按键继续派发给原来的焦点窗口。这也是为什么我在第 2 章坚持用全局键盘钩子来统一捕获按键，而不是依赖候选窗内部的输入框——候选窗只是负责“显示结果”和“渲染选中项”，按键的过滤和选择逻辑其实都是通过钩子拿到键码后再驱动的。

窗口摆放位置我一开始放在屏幕正中间，后来越用越觉得别扭，因为眼睛得从正在输入的位置跳走。最后改成鼠标位置附近，从鼠标光标右下方弹出，同时判断屏幕边缘，如果空间不够就自动向上或向左弹出。这样弹窗始终出现在用户视线边缘，不用刻意寻找，使用起来顺畅很多。

4.2 检索排序的得分公式：前缀命中优先，标签加权

词库内容一多，候选列表的排序就直接决定体验。我见过不少工具用模糊搜索库，引入一堆依赖，其实对几百条的词库来说完全没必要，自己写一个简单的评分排序就够了。我的匹配逻辑大致是这样的：用户输入的过滤词先跟每个条目预设的关键字做前缀匹配，如果是前缀命中，得 100 分；如果是包含匹配，得 60 分；如果该关键字在条目的标签里出现，得 40 分。这里的关键词不是完整句子，而是我预先给每条模板起的短码，比如“wl”对应“问路话术”，“bg”对应“报告模板”。

然后从得分里减去“命中位置”带来的惩罚，也就是说关键词越靠前命中，排序越靠前。最后再加一条使用频率权重：最近使用过的条目会小幅提升排名，方便日复一日用同一批模板的人少按几次方向键。这套算法写起来半小时不到，效果却非常稳定，至少对我来说，回车确认率基本在九成以上。它的核心思想是：绝大多数人记不住完整句子，只记得开头两三个字母，所以前缀匹配必须拥有压倒性优势。

4.3 键盘交互的状态机：回车、上下键、ESC 的完整生命周期

有了不抢焦点的窗口，键盘交互就要靠钩子来处理。我的实现可以抽象成一个小的状态机：空闲状态、输入状态、选择状态、插入状态。

在空闲状态，全局钩子只监听触发组合键。一旦命中，程序切到输入状态，弹出候选窗，同时清空上一次的过滤词。在输入状态，钩子捕获到可打印字符时，会把它追加进过滤词；捕获到上方向键、下方向键时，改变高亮选中项；捕获到回车时，进入插入状态并执行文本发送；捕获到 ESC 时，回到空闲状态并隐藏窗口。插入状态尽量保持短暂，此刻钩子会暂时忽略大多数按键，等文本发送完成再回到空闲。

这里有一个容易漏掉的细节：每次进入候选窗都要把上一次的过滤词和高亮索引清零，否则这一次打开时还会看到上一次搜索的残留结果，非常影响速度。另外 ESC 退出后还要确保目标窗口保持原来的焦点，因为窗口本身没有激活，所以这一步自然就实现了，并不会出现“焦点找回”的窘境。

5. 模板变量与配置管理：从一个“死词库”变成一个“小引擎”

5.1 JSON 配置结构：分组、条目、标签三件套

随着模板越来越多，我把配置设计成了分组结构。为什么选 JSON 而不是 CSV？因为 JSON 天然支持嵌套关系，中文转义和多人协作时也不会由于字段分隔符问题把内容搞乱。基本结构是这样的每组有名称、可选的热键和一组条目；条目里有关键字、内容模板和标签列表。

{ "groups": [ { "name": "售后话术", "hotkey": "Ctrl+Shift+1", "items": [ { "keys": "wl", "content": "请问您的问题具体出现在哪个步骤？", "tags": ["客服", "话术"] }, { "keys": "dz", "content": "收货地址：{address}", "tags": ["地址"] }, { "keys": "cb", "content": "测试账号：{clipboard}", "tags": ["内测"] } ] }, { "name": "代码模板", "items": [ { "keys": "for", "content": "for (int i = 0; i < {n}; i++) { {cursor} }", "tags": ["C#", "循环"] } ] } ] }

配置文件结构简单，但解决了三个实际问题：第一是按业务场景分组；第二是给每个条目一个简短关键字；第三是允许标签跨组检索，方便我搜索“客服”“地址”这类语义词，而不必记住每条短码。JSON 的读写我用了成熟的序列化库，文件保存时先写临时文件再替换，防止程序崩溃导致配置损坏。

5.2 动态变量：日期时间、剪贴板引用与光标占位

如果配置里全是静态文本，那这个工具还称不上“小引擎”。我做了几个简单的动态变量，让模板在插入时替换成实际内容。日期变量写成 {date:yyyy-MM-dd} 的形式，在被选中时用当前日期和时间格式化；{clipboard} 会在插入时读取系统剪贴板当前文本内容，这对“把复制的某个值套进固定句式”的场景特别有用；{cursor} 用来表示希望光标最后停留在模板中间的位置。

注意 {cursor} 的实现并没有想象中那么万能。文本插入之后，大多数编辑器会把光标自动挪到插入内容的末尾，程序没法不经过应用接口就命令“请你把光标放回模板中间”。我的做法是对常见编辑器做尽力而为：先把模板分成光标前和光标后两段，粘贴完前半段后，再通过模拟方向键移动来计算偏移量。这个方法在记事本、常见代码编辑器里表现不错，但在少数自绘控件里完全无效，所以默认策略是“能定位就定位，定位不了就让光标留在末尾”。这是我在使用中学会接受的边界，而不是追求不可能的通用方案。

5.3 配置热加载与多设备同步：FileSystemWatcher 加防抖

工具需要长期驻留，如果每次改配置都要重启，那使用意愿会下降很多。我用文件系统监听来监控配置文件的变更事件，文件一保存就自动触发重新加载。这里有个典型陷阱：文件编辑器在保存时通常不是一次写入而是多次写入，如果每次变更事件都立即重载，会频繁刷新界面甚至读取到半个文件的内容。解决办法很简单：加一个约 200 毫秒的防抖窗口，在最后一次变更事件发生后延迟一小段时间再读取文件。这样既能做到“改完保存立即生效”，又不会把程序搞得神经兮兮。

多设备同步对我来说是刚需，因为我在开发机和备用机上都会用到。做法其实没什么神秘：把 JSON 配置文件放在云同步目录里，每台设备指向同一份文件。由于配置是纯文本，同步时只关注编码一致性，所以统一保存成 UTF-8 无 BOM 格式，避免中文乱码。一台机器上修改保存后，另一台设备只要开着程序，也能自动通过文件监听刷新最新配置，省去了手动拷贝的麻烦。

6. 真实使用半年，我建议你先了解这些问题

6.1 管理员权限窗口下的热键丢失，以及为什么很多工具会让你“以管理员身份运行”

有些应用出于安全考虑会以管理员权限运行，比如某些开发 IDE、系统管理工具。如果我的工具以普通权限运行，那么低级键盘钩子在这些高权限窗口里往往收不到按键，候选窗按不出来，插入自然也无从谈起。这个坑我第一次遇到时完全摸不着头脑，后来才发现不是代码逻辑问题，而是权限级别导致的输入事件隔离。

解决办法其实就一条：让工具本身也以管理员权限运行。我给启动程序加了 manifest 声明，并在入口处做了权限检测，如果发现当前不是管理员权限，就提示用户重启一次。这样做的好处是普通窗口和高权限窗口都能覆盖，坏处是工具会触发系统授权弹窗。我把启动方式打包成一个快捷方式，勾选“以管理员身份运行”，同时保证工具本身在后台不打扰用户。如果你希望完全避免授权弹窗，那就得接受“高权限应用里无法使用工具”这个边界。

6.2 中文输入法状态对模拟输入的干扰：SendInput 的隐藏敌人

当系统输入法处于中文模式时，向目标窗口模拟键盘按键很容易出问题。原因在于你模拟的字母键可能会被输入法当作拼音输入内容，而不是直接作为字符文本交付给编辑器，最后出现的不是预期内容而是拼音联想或候选框。这个现象在用 SendInput 输入 ASCII 内容时尤其明显。

我做了两件事来规避。一是在发送纯 ASCII 内容之前先检查输入法状态，如果当前是中文模式，就先暂时关闭输入法，发送完再恢复原状；二是对于包含中文的内容直接走剪贴板方案，因为剪贴板里的文本不需要经过输入法转换，完全绕开这个隐患。这两个方案组合使用之后，乱码问题基本消失了。

6.3 远程桌面、部分编辑器与密码框的“非标准行为”

远程桌面会话里的行为是最难调的一类。有些远程桌面环境会拦截本地模拟的键盘事件，或者把它们转换成远程会话中的异常输入，导致文本插入不进去。我的经验是：遇到远程桌面场景，暂时放弃模拟按键，把工具改成只帮忙生成文本片段，等手动粘贴；或者干脆在远程会话内部再跑一个实例。这里没有银弹，能做的就是检测到远程会话时降低预期。

除此之外，部分密码框和自绘编辑框也有特殊行为。密码框本身校验输入源，剪贴板粘贴往往不可用，而模拟按键则会受到输入法干扰，所以这两个场景很难兼顾。我在工具里通过简单的窗口类名判断来处理部分情况，但不会强行保证成功，因为安全边界显然比输入便捷更重要。小众编辑器如果有自己的输入管线，也需要不断微调延时参数，这类问题只能靠实测来积累兼容表。

6.4 资源占用与钩子线程的回收：别小看周期性的内存漂移

工具长驻后台，资源占用必须盯紧。低级键盘钩子本身非常轻量，但托管环境里如果回调委托被反复创建而不释放，内存就会悄悄上涨。我在实现里把钩子回调固定成一个静态委托实例，防止垃圾回收阶段出现委托被回收导致程序崩溃或反复挂钩子。

程序退出时需要显式执行 UnhookWindowsHookEx，同时还要把正在监听的资源释放掉。文件监听器、云同步目录下的延迟保存计时器，这些都要在退出时正确处理，否则进程明明退出了，托盘进程的残留还会在任务管理器里徘徊。我在性能上还做了一个小优化：当候选窗处于空闲且没有任何按键交互时，钩子逻辑只做一次简单的整数比较就返回，绝不进入复杂的字符串处理或正则匹配。大半年稳定用下来，内存占用一直稳定在几十 MB 级别，不会对日常使用造成体感影响。

真正用了这么久之后，我的最大体会不是“打字速度变快了多少”，而是那种需要打断思路去复制粘贴的动作真的变少了。如果你想自己动手做类似的工具，我建议一开始就把功能克制住，先实现全局热键、候选弹窗、文本插入三个核心闭环，稳定运行一周之后再往上加变量和自动管理，否则坑和需求叠在一起，排查起来会非常痛苦。这个工具目前依然是我每天都在用的效率小物件，每次顺手插进一段符合场景的话术时，我都会觉得当初那个被枯燥复制粘贴折磨的夜晚，总算有了回报。