Toolkit for YNAB：为 YNAB 网页版补上缺失的开关，但维护已停摆

它解决什么问题：YNAB 网页版缺少的选项

YNAB 的网页版发布后，很多老版本的重度用户发现官方界面缺少一些他们习惯的选项。Toolkit for YNAB 的动机很简单：与其等 YNAB 团队实现这些功能，不如自己用浏览器扩展来做。它不是一个独立的记账软件，而是一层覆盖在 YNAB 网页应用之上的增强层。目标用户是那些对预算流程有明确偏好、愿意花时间配置工具的人。比如你可能想要更紧凑的账户列表、不同的颜色方案、或者一些数据展示上的调整，这些都可以通过扩展的设置页开关来控制。它的价值不在于创造新数据，而在于改变你与现有数据的交互方式。

工作机制：注入脚本与设置页的组合

从仓库布局和构建文档可以看出，扩展的核心是内容脚本（content scripts）。它通过 Web Extension API 在 YNAB 的页面上运行 JavaScript，修改 DOM 和界面行为。功能代码集中在 src/extension/features 目录下，每个子目录对应 YNAB 应用的一个区域，比如账户、预算、报表等。这意味着每个功能都是独立的模块，通过统一的框架注册到扩展中。设置页是另一个关键部分，用户可以在那里逐个开关功能。这种设计让扩展变得非常灵活，你可以只开启自己需要的功能，而不必接受一个整体的改动。但代价是，功能的实现深度依赖 YNAB 当前的 DOM 结构和内部脚本，一旦 YNAB 更新页面结构，某些功能就可能失效。这是所有这类注入式扩展的固有风险，README 里没有回避这一点。

安装与构建：商店下载还是源码编译

对于普通用户，最直接的途径是从各浏览器的官方商店安装。README 提供了 Chrome Web Store、Firefox Add-on Repository 和 Microsoft Edge Add-ons 的链接。安装后，扩展的选项页面会列出所有可用功能，你可以在那里配置开关。如果你想从源码构建，需要先安装 Node.js（>=18.12.1）和 Yarn（>= v1.10.0），然后克隆仓库，运行 yarn install，再运行 yarn build:development。构建产物会出现在 dist/extension 文件夹中，Chrome 用户可以在 chrome://extensions 中开启开发者模式并加载该文件夹。Firefox 用户则需要额外安装 web-ext 工具，然后运行 yarn run manifest:firefox && web-ext run --source-dir dist/extension/。开发时可以用 yarn watch 监听文件变化自动重新构建，或者用 yarn watch:webpack 只编译代码改动而不重新生成索引，后者会明显加快开发速度。

维护模式的现实：新功能已冻结

README 开头就用醒目的方式声明：项目正式进入维护模式。这意味着更新会变得非常稀少，而且大概率只包含 bug 修复，不会再有新功能。项目在寻找新的维护者，联系人是 Discord 上的 Josh Madewell。这是一个重要的信号，任何考虑采用这个扩展的人都应该先读这一条。如果你期望扩展能跟上 YNAB 的每次更新，或者希望看到新功能不断加入，那么现在的维护节奏可能无法满足你。另一方面，维护模式也意味着项目仍然在接收 bug 修复，最近的发布记录显示 v3.22.5 在 2026 年 8 月仍有更新，说明它并未完全死亡，但活跃度明显下降。这更像是一个被社区维护的稳定工具，而不是一个快速演进的实验场。

构建细节与贡献门槛

构建流程使用了 ESLint、Babel 和 Webpack 三件套。ESLint 负责代码风格检查，Babel 将 ES2015 转译为 ES5 以兼容旧浏览器，Webpack 负责将各个入口（后台、弹出页、选项页、内容脚本）打包成单文件。这里有一个值得注意的细节：代码风格遵循 AirBNB 风格指南，这是团队投票决定的。如果你打算贡献代码，必须适应这套风格，否则 ESLint 会拒绝通过。更麻烦的是行尾符要求，代码编辑器必须使用 Unix 风格的 LF 换行符，否则构建会失败，这对 Windows 用户尤其是个坑。这些门槛说明项目对代码质量有要求，但同时也增加了新贡献者的上手成本。如果你只是想用扩展，这些都不需要关心，但如果你计划修复某个 bug，就要做好准备。

局限性与风险：依赖 YNAB 的网页结构

这个扩展最大的局限在于它不是一个独立应用，而是寄生在 YNAB 网页版上。YNAB 的任何前端改动都可能破坏扩展的功能，而维护者又处于维护模式，修复速度可能跟不上。另一个限制是浏览器支持范围，扩展基于 Web Extension API，因此不支持 Safari。如果你只用 Safari，这个工具完全不可用。此外，功能列表虽然丰富，但并非每个功能都适用于所有用户，你需要花时间在选项页上逐个尝试和调整。文档中提到，如果你要开发新功能，最好先在 GitHub issues 上留言，避免重复劳动，这说明项目协作依赖社区沟通，而维护者数量有限，响应速度可能不稳定。最后，扩展会修改 YNAB 的页面行为，这可能会与 YNAB 官方的某些新特性产生冲突，虽然 README 没有明说，但这是注入式扩展的普遍风险。

替代方案：官方功能与自建脚本

最直接的替代方案是 YNAB 官方本身。YNAB 团队一直在更新网页版，有些曾经需要扩展才能实现的功能可能已经被官方纳入。你可以先检查 YNAB 的官方更新日志，看看是否有你需要的选项。另一个替代方案是编写自己的用户脚本，使用 Tampermonkey 或 Greasemonkey 之类的工具，直接针对 YNAB 的页面写自定义代码。这种方式的优势是你可以完全控制代码，不依赖第三方维护者的节奏，但缺点是你要自己处理 YNAB 页面变化带来的兼容问题，而且没有现成的设置界面。相比之下，Toolkit for YNAB 提供了一个统一的框架和设置页，降低了使用门槛，但代价是你必须接受项目的维护节奏。如果你有 JavaScript 能力，自建脚本可能更灵活，但如果你不想碰代码，商店版本依然是更省事的选择。

许可证与维护成本

项目使用 MIT 许可证，这意味着你可以自由使用、修改和分发代码，甚至可以 fork 一个自己的版本。对于企业用户或长期依赖者来说，这是一个重要的优点，因为即使原项目停止维护，你仍然可以基于现有代码自行维护。但这也意味着你必须承担维护成本，包括跟踪 YNAB 的页面变化、修复 bug、重新构建和发布。如果你没有足够的时间和 JavaScript 能力，这个成本可能很高。当前的维护模式已经暗示了这一点，原维护者显然不愿意继续承担这个负担。因此，在采用之前，你需要评估自己是否有能力在必要时接管维护。如果答案是否定的，那么你只能依赖社区，而社区的活跃度目前看来是下降的。

编辑结论

如果你是 YNAB 网页版的日常使用者，并且觉得官方界面缺少某些选项，比如更紧凑的布局、额外的报表或快捷键，那么 Toolkit for YNAB 仍然值得安装，因为它已经打包好、可直接从商店获取，且 MIT 许可允许你自行修补。但如果你指望它持续演化，或者你所在的团队需要稳定的长期支持，那么请不要依赖它，项目已明确进入维护模式，更新频率会大幅降低，且只修 bug 不加功能。安装前请先确认你使用的 YNAB 版本与扩展兼容，并阅读 docs/feature-list.md 中的功能列表，因为并非所有功能都保证在当前的 YNAB 网页版上正常工作。另外，由于扩展会修改 YNAB 的 DOM 和脚本行为，YNAB 官方更新可能导致某些功能暂时失效，你需要接受这种不确定性。最后，如果你打算贡献代码，务必先联系维护者（Discord 上的 Josh Madewell），避免重复劳动，并注意代码编辑器必须使用 Unix 换行符，否则构建会失败。

官方来源

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