uTools 插件开发

写一个能用的 uTools 插件，难在哪

实际动手才会发现坑：plugin.json 字段写错插件打不开；开发时改了代码没生效；preload 被构建工具打包压缩，审核直接挂掉；或者缓存顺手写进 utools.db，插件被下架。这个技能的价值在于把约束前置——写代码之前先明确红线，而不是上线后才从审核意见里学到。

技能如何工作

围绕「规范 + 索引」组织，而不是把所有 API 抄一遍：

• 查文档优先：API 签名、参数、返回值都在 references/utools-api.md，需要时读取对应章节，不凭记忆猜测。
• 两套模板：Vue 3 + Vite 与 React + Vite 各一套目录结构；入口组件统一在 onMounted / useEffect 中注册 utools.onPluginEnter，根据 action.code 做功能路由。
• dev/build 分界：HMR 模式保留 development.main、接入 public/；stripDevelopmentField vite 插件保证 build 后 dist/plugin.json 干净，产物由构建自动生成。

容易踩的几条红线

• preload 源码必须可读：CommonJS 写法、不打包不混淆，preload/ 下放 {"type":"commonjs"}，第三方依赖放同级 node_modules 不编译，只通过 window.xxx 暴露必要能力。
• utools.db 只存用户主动创建的数据：笔记、收藏、用户配置可以；缓存、日志、临时状态、统计计数一律用 dbStorage 或内存变量。这条直接关系能否上架。
• 平台细节：路径一律 path.join()，不硬编码分隔符；type: "window" 的 class 字段仅 Windows 有效；macOS 的 app 字段带 .app 后缀；部分 API 在 Linux 不可用。

什么时候不该用它

技能只覆盖 uTools 插件开发，不涉及插件分发、商店运营或跨设备同步策略设计；它也不替代官方文档——需要某个 API 的完整签名时，正确动作是打开 references/utools-api.md 对应章节。