大家好，
非常感谢大家提供的各种建议，我们非常感激。我们认为已经找到了近期内存问题的根本原因。
此前，在构建时以 root 身份运行 bundle exec rake assets:precompile:build 并不需要 Redis 或数据库连接。但这一行为已发生变化（参考：Introducing pre-compiled JS assets for self-hosters 和 https://meta.discourse.org/t/introducing-a-new-build-system-for-plugins/398713）。
为适应这一变化，我们将 bundle exec rake assets:precompile:build 步骤移至运行时的初始化容器（在执行 db:migrate 等操作之前）。这样可以让该步骤以 discourse 用户身份运行，并具备访问 Redis 和数据库所需的服务权限。
然而，在执行过程中，进程陷入了 lib/plugin/js_manager.rb 中的一个循环。查看 ps -fe 输出，我们发现 pnpm 反复尝试自我安装，导致内存耗尽：
...
discour+ 704 688 5 11:00 pts/0 00:00:00 node /usr/bin/pnpm -C=frontend/asset-processor node build.js
discour+ 718 704 5 11:00 pts/0 00:00:00 node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm
discour+ 729 718 6 11:00 pts/0 00:00:00 node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm
discour+ 740 729 6 11:00 pts/0 00:00:00 node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm
discour+ 754 740 7 11:00 pts/0 00:00:00 node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm
...
# 列表不断增长，导致内存耗尽
在我们的测试中发现，如果将初始化容器以 root 身份运行，并依次执行 npm uninstall -g pnpm 和 npm install -g pnpm@10.28.0，即可解决该循环问题，使插件编译成功完成：
...
[Plugin::JsManager] 正在编译 49 个插件...
[Plugin::JsManager] 插件初始编译完成，耗时 5.82 秒
因此，在我们过度设计基础设施或可能改变架构之前，我想向 @david 请教：是否有计划恢复 assets:precompile:build 的先前行为，使其无需 Redis 或数据库连接即可运行（类似于您在 DISCOURSE_DOWNLOAD_PRE_BUILT_ASSETS: 0 流程中所做的处理）？
另外，出于好奇：为什么以非 root 用户身份运行 node 进程会触发这种递归的 pnpm 安装循环，而以 root 身份运行似乎能避免该问题？
祝好，
Ismael