it-tools：一个值得自托管的开发者工具箱，但先想清楚你要什么

它解决了什么问题，谁在用

it-tools 解决的问题很具体：开发者日常会用到各种小工具，比如 JSON 格式化、时间戳转换、密码生成、UUID 生成、Base64 编解码等。这些工具通常散落在不同的网站或命令行脚本里，每次使用都要打开浏览器搜索，或者记住一堆命令。it-tools 把这些工具集中到一个界面里，统一了操作方式，减少了切换成本。它面向的是开发者和 IT 从业者，尤其是那些经常处理字符串、编码、网络、加密等任务的人。但它的定位不是专业工具，而是日常小工具。如果你需要的是某个领域深度功能，比如全面的 API 测试或复杂的正则调试，它可能不够用。

工具集的结构：从分类到新增流程

从仓库布局看，每个工具都位于 src/tools 目录下，有自己的子目录和独立的 locales 文件。这说明每个工具是模块化的，可以独立开发、测试和翻译。README 提供了一个创建新工具的脚本，运行 pnpm run script:create:tool my-tool-name 会自动生成目录结构和必要的文件，并在 src/tools/index.ts 中注册导入。你只需要把工具加入合适的分类，然后开发功能。这种设计降低了添加新工具的难度，但也意味着工具之间的逻辑是隔离的，你很难让两个工具共享状态或互相调用。如果你需要的是一个集成式的工作台，而不是一堆独立工具，这个结构会限制你。

部署方式：Docker 是主要入口

自托管 it-tools 最直接的方式是使用 Docker。README 给出了两个镜像源：Docker Hub 和 GitHub Packages。命令很简单，例如 docker run -d --name it-tools --restart unless-stopped -p 8080:80 corentinth/it-tools:latest。这样可以快速启动一个运行在 8080 端口的服务。镜像默认监听 80 端口，映射到宿主机的 8080，你可以根据需要调整端口。除了 Docker，它还支持 Cloudron、Tipi 和 Unraid 等平台，这些平台提供了图形化的安装界面，适合不熟悉命令行的用户。但注意，这些第三方平台可能不是官方维护的，更新节奏可能滞后。如果你不使用 Docker，就需要从源码构建，这需要 pnpm 环境和 Node.js，相对麻烦一些。

开发环境：Vue 3 与 pnpm 的配置细节

如果你打算修改 it-tools，需要了解它的开发环境。项目使用 pnpm 作为包管理器，安装依赖用 pnpm install，开发服务器是 pnpm dev，生产构建是 pnpm build。类型检查使用 vue-tsc 而不是 tsc，这是因为 TypeScript 无法直接处理 .vue 文件的类型信息。编辑器推荐 VSCode 搭配 Volar 插件，并且需要禁用内置的 TypeScript 扩展，启用 Take Over Mode 来获得更好的性能。另外，项目使用 i18n，所以编辑器需要配置 i18n Ally 插件，并设置 localesPaths 为 ["locales", "src/tools/*/locales"]。这些配置不是可选的，如果你跳过，开发体验会明显下降。但这也意味着，如果你只是部署而不开发，这些都不需要关心。

测试与代码质量：有单元测试，但深度有限

it-tools 使用 Vitest 运行单元测试，命令是 pnpm test。ESLint 用于代码检查，命令是 pnpm lint。这说明项目有基本的质量保障。但 README 没有说明测试覆盖率或测试的具体范围。从工具数量来看，每个工具可能只有简单的逻辑测试，比如编码解码的正确性。对于像密码生成或哈希计算这类工具，测试是必要的，但可能没有覆盖所有边界情况。如果你打算在生产环境中依赖某个工具的结果，比如使用它生成的密码或加密字符串，建议你自行验证工具的算法是否符合预期，不要假设测试已经覆盖了所有场景。

局限性：它不是一个平台，而是一个集合

it-tools 最大的局限是它不提供任何后端服务或数据持久化。所有工具都在浏览器端运行，这意味着你无法在工具之间传递数据，也无法保存历史记录。比如你生成了一组密码，刷新页面就消失了。对于需要临时使用的场景，这没问题，但如果你希望有一个工具库来管理你的常用配置或生成记录，它做不到。另一个局限是工具的数量和类型是固定的，你只能使用仓库中已有的工具，或者自己开发新的。如果你需要的工具不在列表中，你无法通过配置来添加，必须写代码。此外，项目采用 GPL-3.0 许可，如果你修改并分发给他人，你必须以相同许可开源你的修改。这可能会影响企业内部使用的策略。

替代方案：从单工具到专业软件

与 it-tools 相比，一个常见的替代方案是使用在线工具网站，比如 DevToys 或在线 JSON 格式化工具。它们提供了类似的功能，但不需要自托管，缺点是依赖外部服务，可能涉及数据隐私问题。另一个替代方案是使用命令行工具，比如 jq 处理 JSON，openssl 进行加密操作。这些工具更强大，但学习曲线较陡，且不直观。如果你需要的是图形界面且希望数据留在本地，可以考虑 DevToys 的桌面版，它提供了类似 it-tools 的工具集合，但作为本地应用运行，不需要服务器。DevToys 使用不同的技术栈，但功能重叠度高。关键区别是 it-tools 是 Web 应用，可以通过浏览器访问，适合部署在局域网内供团队使用，而 DevToys 是桌面应用，只能单机使用。

维护与升级：版本节奏与许可影响

从发布记录看，it-tools 的版本号是日期加哈希，比如 v2024.10.22-7ca5933。这种版本命名方式表明项目采用持续部署，每次发布都对应一个代码快照。最近一次发布是 2024 年 10 月，间隔几个月一次，说明维护活跃。但注意，版本号不遵循语义化版本，你无法通过版本号判断是否有破坏性变更。升级时，你需要拉取最新镜像，但 Docker 镜像的标签是 latest，你无法选择特定版本，除非你手动指定镜像哈希。如果你使用了 Cloudron 或 Unraid，升级通常由平台管理，但可能存在延迟。许可方面，GPL-3.0 要求如果你分发修改后的版本，必须提供源代码。如果你只是内部使用，不分发，则不需要。但如果你修改后提供给外部客户，就必须开源。这一点需要法律评估，但基于许可文本，这是明确的要求。

编辑结论

it-tools 适合那些希望快速搭建一个内部工具站点的个人开发者或小型团队，尤其是已经在使用 Docker 或 homelab 环境的人。它不适合需要深度定制或希望集成到现有工作流的团队，因为工具的逻辑和 UI 都是固定的，二次开发需要投入 Vue 和 i18n 的成本。如果你只是偶尔需要几个转换工具，直接使用在线版本或选择更轻量的单工具脚本更实际。在部署前，先确认你需要的工具是否已经包含在列表中，因为新增工具需要自己写代码或提交 feature request。另外，GPL-3.0 许可意味着如果你修改并分发它，你需要开源你的修改，这一点要提前评估。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes