迁移 postmarketOS 最诱人的图景，是下载镜像、刷入设备，一部旧手机随即重获自由。真正有用的流程开始得更早：先明确设备必须完成什么任务，再找到与硬件完全对应的移植页面，并把每个绿色状态格都当成一项有待复现的声明。Linux shell 成功启动，说明实验已经成功；手机挂起六小时后仍能接到紧急电话，则是另一项成果。

这一区分对 postmarketOS 格外重要，因为它既是一个发行版，也是一间把上游 Linux 带到 Android 体系硬件上的移植工坊。项目在 2026 年 6 月 21 日发布新版本时写得很明确：v26.06 面向 Linux 爱好者，现阶段尚未承诺 Android 或 iOS 水平的精致程度。同一份发布说明列出 community 类别下的数十款设备、testing 类别下另外 254 款设备、数项仍在调查的功能回退，以及首批设备进入标准更严格的新 main 类别之前仍在推进的工作。[1] 长长的兼容清单体现了移植覆盖范围；支持承诺仍要落实到具体设备。

合适的采用方式，是分阶段检验硬件。先用备用设备或可移除存储介质，保留一条经过验证、能够回到原厂系统的通道；只有这台具体手机通过预定用途所依赖的各项循环测试，postmarketOS 才能升到正式角色。这样的过程少了先刷机的刺激感，却能让周末项目逐步成为可靠的随身电脑，避免身份验证、地图或电话服务在计划外中断。

封面照片展示的是 PinePhone Pro，它属于少数从设计之初就考虑了移动 Linux 的手机。即使在这类设备上，项目记录里的通话、短信、电池、摄像头和显示输出仍只有部分支持，挂起时接听来电也有限制。专用硬件减轻了一部分移植阻力，对整台设备的完整检验依然要做。[6][10]

先确定任务，再选择操作系统

“替代我的手机”太宽泛，无法转化为测试。更合适的做法，是把任务写成一句明确的话：一台 Wi-Fi 现场终端、一台离线音乐播放器、一台口袋里的 SSH 客户端、一个开发目标、一台自助终端，或是一部使用指定运营商的主力手机。任务不同，验收关卡也会随之变化。

Wi-Fi 终端在调制解调器失效、摄像头表现平平的情况下仍可胜任工作。主力手机则要经受冷启动、挂起、呼入与呼出、双向短信、移动数据、适用地区的紧急呼叫、蓝牙音频、GPS、充电、闹钟，以及一整天脱离充电器的使用。验收还要列出所依赖的银行、公共交通、身份认证或工作应用，其中一些没有原生 Linux 替代品。这些工作负载依赖应在抹除 Android 前查清。

这种收窄任务的方式，恰好体现了 postmarketOS 的一项长处。LWN 的一篇独立综述指出，即使某个移植版本尚未达到日常手机使用标准，旧移动硬件仍可继续服役，用作小型服务器、自助终端或其他用途明确的设备。[9] 重新利用本身自有价值，而且往往能让开放软件与支持尚不完整的硬件找到最清楚的结合点。

把设备页面当作持续更新的物料清单

目录分类说明了维护状态与功能预期，同一类别中的每一行仍然各有差异。项目把设备分为 main、community、testing、downstream 或 archived 等状态，判断标准包括维护者、内核方向、自动化测试和预期设备功能。[2] 类别适合做第一轮筛选，与具体硬件对应的设备页面才是实际起点。

逐项核对厂商、市场名称、代号、地区版本、存储布局，以及文档列出时的面板或主板修订版。同一个零售名称下，也会出现采用不同显示屏、调制解调器或系统级芯片的手机。device-pine64-pinephonepro 这样的软件包名，或 pmbootstrap 中的 vendor-codename 选择，容不得近似匹配：它们会告诉构建系统该组装哪套内核、固件、启动镜像、分区假设和设备特例。[4][6]

接着，带着核验意识查看功能状态格。“Works”后面应继续追查链接中的 issue 历史和安装说明；“Partial”需要转化成一项具体测试；空白或久未更新的条目代表未知，功能状态必须通过实机确认。至少要检查内核类型与版本、GPU 加速、各条音频通路、摄像头、Wi-Fi、蓝牙、GPS、调制解调器的通话/短信/数据功能、充电、挂起、全盘加密和 USB 行为。

PinePhone Pro 把这套方法落到了具体设备上。它的页面把这款手机标为开发平台，记录了接近主线的内核、4 GB 内存，以及可用的 3D 加速、Wi-Fi、蓝牙和 GPS，但通话与短信只有部分支持。页面还说明，设备进入挂起状态后，存在收不到来电和消息的情况；安装 postmarketOS 之前，要先把 Tow-Boot 写入 SPI，之后才能写入可移除存储或内置存储。[6] 这款手机仍有明确的可用范围；只是“手机”这个名称遮住了一项具体故障，而这项故障会让主力机验收失败。

解锁前先备好退出通道

原厂系统仍能启动时，恢复规划就该开始。导出联系人、身份验证器恢复码、照片、消息存档、eSIM 或运营商资料，以及所有无法重新创建的应用数据。更改分区之前，记下准确的原厂固件构建版本，并取得官方恢复包和刷写工具。确认另一台设备能够接收账户恢复提示。回滚方案还要求把备份另存到待修改手机之外。

解锁 bootloader 经常会抹除用户数据，不同设备的恢复方法也各不相同。通用安装页面特意把读者引回设备专属说明，明确以各款手机自己的刷写步骤为准。[3] 写清进入 bootloader 或恢复模式的方法、主机识别手机的方法、会被改动的分区，以及恢复原厂系统的步骤。只要其中一项仍无答案，迁移就仍处在调研阶段。

若移植版本支持可逆的首次启动，应优先采用这种方式。照片中的 PinePhone Pro 安装 Tow-Boot 后，可以从准备好的 microSD 卡启动；一些源自 Android 的移植版本可以临时启动内核、使用 SD 卡或安装到 userdata，另一些则要求更改内部启动分区。[4][6] “外置”依旧带着风险，因为 bootloader 仍有被改动的情况；不过，它让根文件系统与内置存储保持分离，也更方便比较安装前后的状态。

项目编写了 postmarketOS 用户数据备份与恢复文档，这和保留厂商固件及分区状态分属不同层次。[7] 两者都要保留：一台能够恢复原厂状态的设备，以及一个可以还原的 Linux 主目录，解决的是两类故障。

让 pmbootstrap 把选择摆到台面上

对于已有支持的设备与界面组合，预构建镜像是最短的安装途径。若目标包含理解或控制安装过程，pmbootstrap 更有价值。它的初始化流程要求操作者选择发布通道、厂商、代号、用户界面和其他设备选项；pmbootstrap install 负责构造根文件系统，flasher flash_rootfs、flasher flash_kernel、export 和 --sdcard 等命令则对应不同的交付方式。[4]

这些命令名分别指向不同的交付方式，实际顺序以当前设备页面为准。有的设备只需要根文件系统，有的还需要单独的内核镜像、Android recovery zip、特定 bootloader 或名称精确的分区。执行当前设备页面列出的命令序列。保存 pmbootstrap 配置、工具版本、所选通道、镜像校验和与终端记录，让实验能够复现，免得日后只靠记忆还原。

加密要在安装前决定。pmbootstrap install --fde 可以为受支持的安装方式构建加密系统，但设备页面会进一步限定通用能力的适用范围，甚至给出相反说明。以 PinePhone Pro 为例，页面把全盘加密列为一项功能，同时警告当前安装仍有问题，并链接到相关 issue。[4][6] 一部要保存账户或现场数据的手机，如果把“以后再加密”留到日后处理，就应判定采用验收未通过；除非文档已经给出确实存在的原地加密方法。

验证手机的工作循环，别只看启动界面

第一次启动后，按固定方案试用，少做漫无目的的点按探索。一套实用的 72 小时检验可以分为五个循环：

1. 启动与恢复。 完成五次冷启动，在没有主机电脑的情况下进入启动菜单，并实际演练文档中的恢复流程。确认系统更新或电池耗尽后，即使设备进入陌生模式，也能按记录的步骤恢复。
2. 挂起与供电。 测量一夜待机耗电，反复唤醒设备，使用实际需要的适配器充电，并测试低电量行为。只能在保持唤醒时工作的手机，实质上是一台台架电脑。
3. 无线通信与音频。 使用预定运营商，测试呼出与呼入、双向短信、移动数据、Wi-Fi 漫游、蓝牙重连、麦克风路由、扬声器、耳机，以及 GPS 冷启动。挂起一小时后，再测试一次来电。
4. 存储与安全。 重启并走完加密解锁流程，填充足够多的存储空间，以暴露分区假设；从备份中恢复一个样本文件，并确认旧手机离线后仍能访问机密信息。
5. 更新与回滚。 完成一次常规系统更新，重启两次，再次确认关键功能，并主动恢复已保存的配置或数据。以更新后的手机仍能完成预定任务，作为更新流程通过测试的标准。

记录通过、失败、部分通过和未测试四种状态。把每项故障链接到设备页面或 issue tracker，并附上内核与软件包版本。这样，“postmarketOS 能在我的机型上运行”就从个人经验转成了其他用户或维护者可以利用的证据。

根据图形通路和内存选择界面

postmarketOS 可以提供 Phosh、Plasma Mobile、Sxmo、传统桌面和面向控制台的环境，但界面选择要服从内核与图形支持状况。项目的界面指南主要建议在使用接近主线内核且图形加速正常的设备上采用现代移动 shell；指南同时提醒，一些 downstream 内核移植版本缺少 Phosh 所需的 DRM 支持，而以软件渲染运行 Plasma Mobile 时，性能会很差。资源紧张的设备更适合轻量 shell 或控制台。[5]

检验期间只选一种界面。同时更换 shell、init system、内核分支和调制解调器软件栈，会让前后比较失去意义。在相同的屏幕亮度和无线通信条件下，记录空闲内存、从解锁到桌面可用的时间、应用启动时间与电池消耗。如果设备的任务是自助终端或 SSH 装置，视觉上最简单的选项通常也有最小的故障面。

把更新纳入采用流程

v26.06 稳定版基于 Alpine Linux 3.24，包含当前的 Phosh、Plasma Mobile、systemd、调制解调器和通用内核工作；发布说明同时列出了设备专属的功能回退，以及无人维护的移植版本退回 testing 类别的情况。[1] 这种透明度有利于项目健康，也提醒使用者：维护状态会发生变化。提升设备角色之前，要明确由谁关注发布说明、设备多快需要打补丁、如何分阶段更新，以及哪些事件会让手机重新降为辅助设备。

Duranium 展示了一个更接近家电式系统的未来：它采用经过验证的镜像式 A/B 更新与回滚。当前的设备采用流程仍需逐项检验。项目把它描述为面向测试者的开发中工作，存储空间和固件要求也更高：两个 5 GB 的 /usr 槽位、UEFI 支持和设备专属的启动工作；安全启动与验证启动仍未完成。[8] 这套设计之所以令人鼓舞，正因为它明确列出了移动 Linux 仍然欠缺的可靠性设施。路线图描述未来方向，运行保证只来自已经完成的功能。

决定何时提升设备角色

postmarketOS 很适合配有恢复硬件的爱好者、专注于某个移植版本的贡献者，或把一批相同设备改作特定用途的小型技术团队。当任务更看重常规 Linux 用户空间、长期延续的上游工作和设备所有者的控制权，对商业应用目录的依赖较低时，它同样会是更合适的系统。

以下条件会削弱它作为主力手机的适配度：用户无法容忍漏接电话，没有第二条身份验证通道，依赖当前缺失的应用，或无法恢复原厂镜像。若要用于设备群，缺少备用机、版本固定、分阶段更新和负责具体设备移植版本的人员，也表明采用时机尚未成熟。

提升设备角色要同时满足四项条件：预定任务已在准确的硬件变体上通过测试；恢复流程已经演练；加密与备份已经验证；一次更新周期过后，关键工作循环仍然完整。在此之前，把 postmarketOS 留在可移除存储介质或辅助设备上。迁移依然产生了价值，因为一项兼容性声明已经变成一份经过测量的硬件记录。

Sources

1. postmarketOS，“v26.06: Alpen Avocado”（2026 年 6 月 21 日）——涵盖发布受众、Alpine 基础、设备分类、已知问题和维护方向。
2. postmarketOS Wiki，“Device categorization”——涵盖 main、community、testing、downstream 和 archived 移植版本的分类标准与维护预期。
3. postmarketOS Wiki，“Installation”——涵盖预构建镜像与 pmbootstrap 两种方式，并以设备专属说明作为实际安装依据。
4. postmarketOS，pmbootstrap 使用文档——涵盖初始化、镜像构造、导出、模拟、加密和设备专属刷写命令。
5. postmarketOS Wiki，“Interface”分类——涵盖 shell 选择、图形前提、资源限制和界面软件包管理。
6. postmarketOS Wiki，“PINE64 PinePhone Pro”——涵盖硬件、功能状态、Tow-Boot 依赖、存储方式、加密说明和恢复细节。
7. postmarketOS Wiki，“Backup and restore your data”——已安装系统的用户数据备份与恢复指南。
8. postmarketOS，“Introducing Duranium: a more reliable postmarketOS”（2026 年 3 月 17 日）——涵盖不可变布局、A/B 镜像、存储与 UEFI 要求，以及当前测试状态。
9. Koen Vervloesem，“postmarketOS: Linux for phones and more.”，LWN.net，2024 年 7 月 3 日——独立项目综述，涵盖设备支持限制与重新利用设备的用途。
10. Martijn Braam，“PinePhone-Pro-Plasma-Mobile”（2022 年 3 月 26 日），Wikimedia Commons——文章图片来源。