在 Android 手机的 PRoot Ubuntu 里跑通这个 Astro 博客的安装、检查与构建

背景：想验证的是「手机上能不能把仓库跑到 dist」#

我想验证的问题只有一句话：不打开电脑，只靠一台 Android 手机，能不能把这个博客仓库从零克隆下来，并跑完安装、静态检查、类型检查和生产构建。

这个站是 Astro 7 + Firefly 主题，仓库在 master 分支、只有 1 个提交、单一远程 origin、3 篇文章目录，同时放着 wrangler.jsonc 和 vercel.json 两套部署配置（后者的 buildCommand 就是 pnpm build）。也就是说手机端能负责的只是「把 dist 产出」，上线仍然交给外部平台——这也决定了本文的范围止于「跑出 dist 并在本地预览」，不含部署。

手机是 Android 13，上面套了一层 PRoot 式的 Ubuntu 24.04.3 LTS 用户态。下面三条输出足以判断这不是虚拟机，而是挂在 Android 应用数据目录里的 PRoot 用户态：

1
$ uname -a
2
Linux localhost 5.15.123-android13-8-00008-g3ca6a2912c7e-ab11087001 #1 SMP PREEMPT ... aarch64 GNU/Linux
3
$ grep PRETTY_NAME /etc/os-release
4
PRETTY_NAME="Ubuntu 24.04.3 LTS"
5
$ env | grep -i proot
6
PROOT_TMP_DIR=/data/user/0/dsh.android.client/files/linux/tmp
7
PROOT_LOADER=/data/app/~~.../lib/arm64/libprootloader.so
8
PROOT_L2S_DIR=/data/user/0/dsh.android.client/files/linux/ubuntu/.l2s

内核和用户态不同源（Android 内核 + Ubuntu 用户态），路径又都落在 /data/user/0/... 下，所以本文的判断标准是「能不能跑通」；耗时数据是后面用文件与日志时间戳反推的，不是秒表读数。

除标注 package.json 的三行外，上表都是当场用命令读出来的。

方案：五步，从克隆到预览#

这条链路是五条命令，全部在本轮实际执行过。前四步负责产出，最后一步 pnpm preview 起本地静态服务，用来确认产物和路由真的能访问。

1
# 1. 克隆：浅克隆，只取 master 最新一次提交
2
cd ~ && git clone --depth 1 https://github.com/WirepullerDX/blog.git Blog && cd Blog
3

4
# 2. 安装依赖：用 --frozen-lockfile，保证不改 lockfile
5
pnpm install --frozen-lockfile
6

7
# 3. 静态检查与类型检查
8
pnpm check
9
pnpm type-check
10

11
# 4. 生产构建
12
pnpm build
13

14
# 5. 预览产物：另起一个进程，默认监听 localhost:4321
15
pnpm preview

本轮实际目录就是 /root/Blog（root 用户的 ~ 即 /root）；如果你不是 root，把 ~/Blog 换成自己的路径即可。

1
$ ls .git/shallow
2
94bc8eb4f1a49c08297e4d6c834749066e0f38b2
3
$ git rev-list --count HEAD
4
1

问题：几个需要提前知道的前提#

解决：用时间戳反推耗时，标出没验证的部分#

耗时不用秒表，而是读文件和日志的时间戳：npm 日志的文件名是子进程启动时刻，日志文件的 mtime 是它退出时刻，dist/ 的 mtime 是 Pagefind 收尾时刻。误差在秒级，但每一条都能复现：

1
$ stat -c '%y %n' package.json node_modules/.modules.yaml \
2
    ~/.local/share/pnpm/store/v11/projects \
3
    ~/.local/share/pnpm/store/v11/index.db dist
4
2026-10-30 05:36:22.072541108 +0000 package.json
5
2026-10-30 05:37:55.232541073 +0000 node_modules/.modules.yaml
6
2026-10-30 05:36:57.784541095 +0000 /root/.local/share/pnpm/store/v11/projects
7
2026-10-30 05:37:56.116541072 +0000 /root/.local/share/pnpm/store/v11/index.db
8
2026-10-30 05:41:22.200540994 +0000 dist
9
$ ls -1 --time-style=full-iso -l ~/.npm/_logs/
10
-rw-------. 1 root root 1643 2026-10-30 05:39:50.920541029 +0000 2026-10-30T05_39_43_838Z-debug-0.log
11
-rw-------. 1 root root 1307 2026-10-30 05:41:22.324540994 +0000 2026-10-30T05_41_17_780Z-debug-0.log
12
...（共 7 个日志，此处只留首尾两条）

每个日志文件里的 argv 能读到对应脚本（例如 "exec" "--" "tsx" "scripts/generate-lqips.ts"），文件名的时间是启动时刻，ls 那一列 mtime 是退出时刻。

astro build 没有自己的 npm 日志（它是项目依赖里的可执行文件），它夹在 generate-vndb-covers 退出（05:39:58）和 prune-pio-assets 启动（05:41:02）之间。把它和其他环节拼起来，pnpm build 的 99 秒可以拆成下表：

八段相加约 97 秒，加上环节之间启动 npx 的零碎间隙，05:39:43.8 → 05:41:22.2 合计 98.4 秒，与 mermaid 里的「约 99 秒」对得上。

两个容易写错的地方值得单独说明：

• generate-vndb-covers 是空跑。src/config/siteConfig.ts 里 vndb 的 mode 是 static、userId 是 u358128，但 downloadCovers 为 false；public/vndb-covers 目录也不存在。所以 05:39:54 只是这个子进程的启动时刻，之后没有任何封面被下载，那 3.5 秒是 tsx 启动与判空后退出的开销。
• astro build 的 63.8 秒可以近似看作纯编译时间：因为上游 VNDB 步骤空跑、这一段没有任何网络下载。

结果：检查与产物的实测输出#

pnpm check：

1
$ pnpm check
2
Result (259 files):
3
- 0 errors
4
- 0 warnings
5
- 0 hints

这里的 259 files 是诊断覆盖的文件规模，跟文章数无关（dist/posts 下只有 3 个目录）。我在加入这篇文章前后各跑一次，两次输出完全一致，耗时分别是 79.9 秒和 81.7 秒——运行时刻与机器负载不同就会有差异，所以这两个数字只作量级参考，不当作基线。

pnpm type-check（tsc --noEmit --isolatedDeclarations）退出码 0，耗时 9.3 秒。

在时间线上，检查与类型检查只能发生在这段空档里：05:37:56（安装落盘）到 05:39:43（构建第一个子进程启动）共 107 秒；按本轮实测（check 79.9 秒 + type-check 9.3 秒）合计 89.2 秒，余下约 18 秒是 pnpm/astro 的启动开销。

构建产物这边，把本文加入之前的那次构建里，dist 共 16 MB：dist/index.html 309549 字节、dist/rss.xml 1875 字节、dist/sitemap-index.xml 192 字节、dist/posts 1.2 MB、dist/pagefind 626 KB；加入本文重建后 dist 变成 17 MB、dist/posts 1.7 MB。搜索索引的页数可以直接从入口文件读出来：

1
$ node -e "const d=require('./dist/pagefind/pagefind-entry.json');
2
  console.log(d.version, d.languages['zh-cn'].page_count)"
3
1.5.2 8

也就是说：从 05:36:22 检出到 05:41:22 Pagefind 收尾，共 300 秒（约 5 分钟），其中安装 59 秒、构建 99 秒，检查与类型检查全绿。那次构建索引出 7 页（当时站里 3 篇文章），加入本文后重建，索引页数变成 8。

预览用的是 pnpm preview，默认监听 localhost:4321。注意它只绑 IPv6 回环，用 127.0.0.1 连会直接连接失败，得写 localhost：

1
$ for u in /posts/astro-build-on-android-proot/ /og/astro-build-on-android-proot.png /rss.xml; do
2
    printf "%-42s " "$u"
3
    curl -s -o /dev/null -w "%{http_code}\n" "http://localhost:4321$u"
4
  done
5
/posts/astro-build-on-android-proot/       200
6
/og/astro-build-on-android-proot.png       200
7
/rss.xml                                   200

自己生成的 1600×900 封面 cover.webp 是 48102 字节，构建后由 Astro 输出成 _astro/cover.*.webp，预览里取回来同样是 48102 字节、HTTP 200，说明封面确实被当作图片资源处理了，不是被跳过的静态文件引用。/og/astro-build-on-android-proot.png 返回 200 则说明 siteConfig.post.generateOgImages 为 true 时构建会真的产出分享图。反过来，/posts/astro-build-on-android-proot（不带结尾斜杠）在本地静态预览里是 404，别把这个 404 当成文章没生成；同一路径在 Cloudflare Pages 的预览部署上返回的是 308 并跳到带斜杠的地址，两条链路行为不一样，别拿本地的 404 去判断线上。

总结#

五步都跑通了：安装、pnpm check、pnpm type-check、pnpm build、pnpm preview 在一台 Android 手机的 PRoot Ubuntu 用户态里全部完成，dist 产物齐全，文章路由和封面在本地预览里都是 200。

真正的限制不在「能不能跑」，而在两件事：一是内存余量有限，得把节奏放慢、避免并发；二是提交、推送、部署、对象存储上传这些环节在这个环境里没有凭据，只能留到有授权的环境再做，不能凭一次成功构建就宣布上线。

下一步只剩真实部署这一环：推送、PR、Cloudflare Pages 预览。这个站最初从 Firefly 模板搭起来的过程，写在把博客搭到 Cloudflare：从 Firefly 模板到 R2、Twikoo 和自动部署里。