企业官网建设流程全解析

我的抽屉里躺着三台旧手机。这不是什么稀罕事，几乎每个折腾过数码产品的人都有这么个角落：一台屏幕碎了但还能开机的、一台电池不太耐用的、一台换了新机后彻底退休的。放在以前，它们的归宿大概率是回收平台或者某个吃灰箱。但在折腾了大半年以后，这三台机器如今正24小时不间断地在我家里干活——一台负责全屋的DNS过滤和广告拦截，一台挂着下载任务，还有一台在跑本地大语言模型。

这就是我想说的"算力芯生"。闲置手机不是电子垃圾，而是一个被严重低估的算力池。它有一颗完整的移动SoC，有CPU、GPU、NPU、DSP，有几GB内存，有几百GB闪存，还有网卡、蓝牙、传感器，甚至摄像头和麦克风。这些东西打包在一起，功耗只有几瓦，成本几乎为零。只要给它一套合适的软件环境，它就能从"旧手机"变成一台安静、省电、全天候在线的家庭服务器。

这篇内容就是我从零开始把闲置手机改造成算力节点的完整复盘，包括硬件能力怎么评估、系统环境怎么搭、常见应用怎么部署、以及那些跑一段时间才会暴露出来的坑。无论你是刚知道Termux的小白，还是已经在折腾自托管的老手，多少都能捞出点能直接用的东西。

1. 一台旧手机到底藏了多少算力

先说一个反直觉的事实：一台2020年左右的中高端手机，算力水平放在今天依然相当能打。它的CPU单核性能可能比不过新款台式机，但作为家用服务器，它跑的大多数任务其实是网络转发、轻量数据库、脚本自动化和一些老的编译工作，这些恰恰是手机芯片的舒适区。更重要的是，整套系统的功耗通常只有3到8瓦，对比一台待机就几十瓦的迷你主机，优势非常明显。

1.1 手机、树莓派、迷你主机和云服务器的真实差距

我当初也纠结过：与其折腾旧手机，不如买个树莓派或者二手迷你主机。后来把账算了一遍，发现每种方案的定位其实完全不同。

看完这张表就明白，手机的优势从来不是接口丰富，而是算力密度和功耗比。运行同样一个轻量服务，手机可能只需要树莓派一半的功耗，却拥有比树莓派更快的CPU性能。当然，它也有致命短板：没有网口、存储扩展困难、系统环境不是标准Linux。所以正确的态度不是"手机取代服务器"，而是"让手机去干活力换来的地方"。

1.2 为什么多数人从没意识到手机能当算力节点用

原因很简单，手机出厂就被锁死在一个面向消费者的系统里，厂商希望你用它刷视频、拍照、玩游戏，而不是把它变成一个无头服务器。Android的底层确实是Linux内核，但上层那套应用框架和国际惯例的Linux服务器环境完全是两回事。不要说普通人，很多程序员也天然觉得"服务器就得是x86 + systemd + Docker那一套"，看到手机上没法直接跑Docker，就放弃了。

其实绕过那层安卓UI，手机底层的Linux能力一直存在。高通、联发科、麒麟这些移动SoC在硬件层面就是一整套完整的计算机系统，而且因为移动端对省电的极致追求，它的电源管理和调度机制做得比很多桌面设备还要精细。只要找到合适的入口，它就能像一台小服务器一样稳定输出算力。

1.3 这个话题适合谁，不适合谁

我必须先把丑话说在前头。把旧手机变服务器，有一个天然的筛选门槛：你喜不喜欢折腾。整个过程中需要接触命令行、环境变量、进程管理这些概念，不是说做不到，而是需要一点耐心。

适合这玩法的人，大概是下面这几类：

• 学生党：预算有限，但手上不缺旧手机，想搭个自己的实践环境。
• 自托管爱好者：家里已经跑着不少服务，希望能用极低成本分担一部分边缘任务。
• 隐私党：想把DNS、广告过滤、数据同步这些敏感操作放在自己手里，而不是交给云端。
• AI尝鲜者：想安全地跑一个本地大模型，但又不想花大价钱买新硬件。

不合适的也有：如果你完全不想碰命令行，希望拿回来就有一个漂亮的图形界面，那旧手机路线大概率会让你抓狂。这种情况下，直接买个NAS或者成品迷你主机更省心。

2. 拆解一部手机的"算力家底"

在动手搭环境之前，先搞明白手里这台旧手机到底能干什么。不是每台手机都适合当服务器，关键要看芯片、内存和系统状态。

2.1 移动SoC的异构算力：CPU、GPU、NPU各干什么活

移动SoC比很多人想象中复杂，它不是一个单纯的多核CPU，而是多种计算单元的集合体。

CPU部分：通常采用大小核架构，比如骁龙的"1+3+4"或"1+2+3"结构。大核负责突发高负载，小核负责后台常驻任务。这种调度模式天然适合服务器场景——大部分时间负载很轻，只有处理请求或编译打包时才会冲高，正好匹配大小核的调性。而且2020年以后的芯片大核心基本都是ARM A77/A78/X1这个级别，性能远超树莓派4的A72，甚至能摸到入门级x86的边。

GPU部分：手机GPU能耗比非常优秀，比如Adreno或Mali系列，在视频编解码、图像处理、小规模并行计算上都有一定能力。最实用的场景是视频转码和图像批处理，一部手机就能完成摄像头视频流的实时转码，这在智能家居场景里非常有用。

NPU/DSP部分：这是移动SoC最特别的地方。很多旗舰芯里的NPU算力是以TOPS为单位的，比同时代的PC显卡能效高得多。但问题是厂商的NPU驱动基本不对外开放，第三方Linux环境下很难直接调用。所以这条路线目前只能"观望"，真正跑AI还是得靠CPU和GPU。

2.2 内存、闪存和网络：最容易忽略的硬约束

算力只是故事的一半，内存和存储才是真正的天花板。

现在市面上的二手手机，比较舒服的配置是8GB内存起步，12GB的也不少。8GB内存跑常规服务完全够用，甚至在proot容器里跑一个0.5B参数的量化大模型也能勉强塞下。如果是6GB以下的机器，老老实实做DNS过滤和下载任务就行，别想AI了。

闪存方面，手机用的是UFS 3.x/4.x，顺序读写速度在几百MB/s到2GB/s之间，随机读写性能比机械硬盘好得多，但跟NVMe固态还有差距。作为对比，树莓派4用的是SD卡或USB固态，手机闪存的性能反而更稳。不过手机存储无法直接扩展，所以要提前规划好哪些数据放本机，哪些放家庭NAS。

网络是手机当服务器最大的障碍。绝大多数手机只有一个Wi-Fi和蜂窝网络，没有标准网口。Wi-Fi在近距离下跑几百Mbps没问题，但延迟和稳定性确实不如有线。而且手机息屏后Wi-Fi策略可能被系统干预，这对长时间跑服务有影响。后续我会在第五部分单独讲怎么处理这些网络层面的坑。

2.3 一台旧手机能接哪些任务：场景与资源需求速查

根据以上能力边界，我整理了一张实用的任务匹配表：

这张表其实揭示了一个核心观点：手机作为算力节点，最合适的工作是"边缘侧的小而美任务"，而不是"大而重的集中式计算"。认清这个定位，后面选场景就不会头铁。

3. 从安卓到Linux：三种路线怎么选

手机里跑的Android系统本身就有Linux内核，但那层壳挡住了绝大多数服务端软件。要让手机真正变成可管理的算力节点，核心工作就是给它一个可用的Linux用户态环境。

3.1 三种主流方案的优劣势对比

我把目前可落地的方案分成三条路线，它们的侵入性和顺手程度差别很大：

路线A：Termux + proot-distro（零风险入门）

Termux是一个运行在Android应用层的终端模拟器，不需要root，不需要解锁Bootloader。它自带一个软件包仓库，能装Python、Node.js、Git、CMake等常用工具。proot-distro则是在Termux里模拟一个完整的Linux发行版文件系统，比如Debian或Ubuntu。这种方案最大的好处是对手机系统毫无破坏，随时可以卸载消失，适合新手和谨慎党。

代价是性能有一定损耗。proot是用户态模拟，不是真正的容器技术，涉及系统调用的程序会慢一些。但从实际操作看，跑常规服务、脚本、甚至编译中小型项目都没问题。

路线B：Linux Deploy + root（性能更佳）

Linux Deploy是一个被很多人忽略的老牌工具，它通过chroot方式挂载Linux发行版，性能比proot好很多，接近原生。但它要求设备已经root。对于手上这台旧手机，如果考虑刷面具（Magisk）或者解锁Bootloader获取root权限，这条路线比proot更能压榨性能。

路线C：直接刷原生Linux（进阶玩家）

对部分机型，社区已经移植了postmarketOS、Droidian或者Ubuntu Touch这类原生Linux系统，刷完以后手机直接变成一个带屏幕的Linux主机。这是最彻底、最漂亮的方案，Linux支持最好，但风险最大：可能刷成砖、相机和基带不可用、系统更新全靠社区维护。

三条路线怎么选？我的建议很简单：第一次尝试，无论如何先走路线A。等玩明白哪些服务真正需要性能，再考虑要不要给手机root或者刷原生Linux。这个循序渐进的过程能帮你避免很多不必要的风险。

3.2 Termux + proot-distro完整搭建步骤

下面是我验证过很多次的步骤，每一步都踩过坑，按顺序执行基本能一次成功。

第一步，安装Termux。注意不要从Google Play下载，那个版本更新滞后且包管理受限，建议去F-Droid下载最新版。安装完成后打开App，先执行：

termux-setup-storage pkg update && pkg upgrade

这个过程中会让你授权存储权限，建议给，后面下载文件要用。

第二步，安装proot-distro并部署Debian：

pkg install proot-distro proot-distro install debian

等待下载完成后，执行登录命令：

proot-distro login debian

你会看到提示符前多了root身份，这就已经进入Debian环境了。先做最基本的初始化：

apt update && apt upgrade -y apt install curl wget nano htop openssh-server rsync

到这里，一个基础Linux环境就跑起来了。注意这个环境默认是root用户，没有设置密码，后续如果要在容器内跑SSH，需要设置root密码或者创建普通用户。

第三步，配置SSH。在proot环境里编辑SSH配置文件：

sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config mkdir -p /run/sshd passwd root service ssh start

从电脑上测试连接：

ssh root@手机IP -p 8022

如果连不上，大概率是Termux没有申请后台运行权限，后面保活部分会细说。这里有一个关键细节：SSH监听端口建议换成非常规端口，比如8022，避免和局域网内其他SSH设备冲突，也减少扫描风险。

3.3 开机自启与保活：让服务不因为锁屏就罢工

这是整个项目里最容易让人崩溃的一步。Android系统出于省电考虑，会在手机锁屏一段时间后杀掉后台进程，Termux默认也会被杀。解决思路是从两个层面堵住漏洞。

系统层面，在Android设置里找到Termux的电池优化选项，把它设为"不受限制"，同时在最近任务列表里给Termux加上锁定。这个操作不涉及任何破解，只是告诉系统"这个应用很重要，别杀它"。

Termux内部，使用权限工具维持唤醒锁：

pkg install termux-api termux-wake-lock

然后安装Termux:Boot插件，在~/.termux/boot/目录下创建启动脚本，让手机重启后自动拉起环境和服务。我自己的启动脚本大致长这样：

#!/data/data/com.termux/files/usr/bin/bash termux-wake-lock sleep 10 proot-distro login debian -- /usr/sbin/sshd # 其它服务通过nohup或supervisor在容器内自行拉起

这个脚本会在开机时自动执行。有了它，手机断电重启后不需要人工干预，服务会在几十秒内全部回到可用状态。

4. 最能出成果的四个落地场景

环境搭好以后，真正考验选择能力的是跑什么服务。我把自己实际跑过、不那么容易翻车的四个场景列出来，每个都能在半天内搞定，且能满足真实需求。

4.1 用AdGuard Home做全屋DNS过滤

这是手机算力节点最简单的盈利场景。以前家里的路由器DNS是运营商的，看视频时总有各种广告和统计域名跳来跳去。在自己的DNS服务器上做过滤，等于全屋设备自动生效，不依赖任何客户端App。

在Debian容器里安装AdGuard Home，从GitHub Release页下载对应arm64的二进制包：

mkdir -p /opt/adguardhome && cd /opt/adguardhome curl -sSL https://github.com/AdguardTeam/AdGuardHome/releases/latest/download/AdGuardHome_linux_arm64.tar.gz | tar -xz ./AdGuardHome -s install

运行后访问http://手机IP:3000进行网页初始化，设置DNS监听端口为53，管理面板端口自由选。配置完成后，把家里路由器的DNS指向手机IP，全屋的广告过滤就生效了。

实测效果：普通网页里的横幅广告、视频前贴片广告、App里的统计追踪域名，基本都能被挡掉一大半。某些配置不当的网站可能会加载缓慢，那是因为被过滤的请求触发了重试超时。这个需要在AdGuard Home的白名单里逐步调整，运行一周后会越来越稳定。

4.2 无人值守下载机：aria2 + AriaNg

旧手机当下载机，功耗低到可以忽略不计，而且挂着也不影响白天打电话刷视频。Termux或Debian容器里安装aria2，开启RPC模式，配合AriaNg这个网页前端，在任何设备上都能管理下载任务。

apt install aria2 aria2c --enable-rpc=true --rpc-listen-all=true \ --rpc-secret=你的密码 \ --dir=/sdcard/Download \ --max-concurrent-downloads=5 \ --file-allocation=none \ --continue=true

用浏览器打开AriaNg的页面，填上RPC地址和密钥，就能看到设备列表和干载任务了。几个小细节：--continue=true确保断点续传有效，--file-allocation=none避免在UFS闪存上预分配大文件浪费写入寿命。

如果下载的是普通HTTP文件，aria2的多线程加速十分明显。实测同一文件，手机挂在Wi-Fi下跑aria2比电脑浏览器下载快上不少。当然，BT任务受peers影响大，建议优先用它下载HTTP/FTP资源。

4.3 轻量智能家居中枢：Node-RED + MQTT

很多人一说智能家居，第一反应就是Home Assistant。但Home Assistant对存储和内存要求高，在手机上用proot跑很容易遇到数据库损坏和升级问题，实际体验并不好。我的做法是装Node-RED + Mosquitto（MQTT Broker），用轻量级的节点做自动化中枢。

先装Mosquitto：

apt install mosquitto mosquitto-clients

再装Node-RED：

curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/install-node-red.deb.sh | bash

装完以后，ESP8266或ESP32上的温湿度传感器通过MQTT上报数据，Node-RED里的流程订阅主题，再根据规则触发红外遥控器或智能插座。整个过程完全本地化，不依赖任何云平台，而且Node-RED的流程编辑是在浏览器里拖拽完成的，比写代码直观得多。

有一说一，Node-RED这套方案的学习曲线比Home Assistant平滑很多。Home Assistant是一个大而全的一体化平台，而Node-RED更像是一个乐高积木盒子，哪里需要自动化就搭哪段流程。对旧手机这种算力节点来说，"刚刚好"比"大而全"重要。

4.4 在旧手机上跑本地大语言模型

这是整个项目里最让我兴奋的场景。llama.cpp这个项目让大语言模型可以在纯CPU上运行，而手机回来就是一台近乎免费的推理设备。在Termux的原生环境里编译llama.cpp：

pkg install git cmake make git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPE=Release cmake --build build -j$(nproc)

然后下载一个量化过的轻量级模型，比如Qwen2.5-0.5B的GGUF量化版，放到models/目录下，用任意.gguf文件路径运行：

./build/bin/llama-cli -m models/qwen2.5-0.5b-instruct-q4_k_m.gguf -p "写一段关于旧手机的短诗" --temp 0.7

实测在8GB内存的骁龙中高端手机上，0.5B的量化模型每秒能生成十几到二十几个token，虽然不如云端快，但优势在于完全离线、隐私不出门，而且不花一分钱。更小的模型或手机内存更大的话，吞吐量会更好。

如果你对这条路感兴趣，可以尝试1.5B到3B级别的量化模型，这是手机内存和速度的甜点区间。再往上走，吞吐量会明显下降，体验就会变成"等等等等"。

4.5 远程访问自己的服务：组网比端口映射更安全

手机服务跑起来了，出门在外还想访问怎么办？两个选择：端口映射和组网。端口映射就是在路由器上把公网请求转发到手机IP，简单但等于把设备暴露在公网，扫描和暴力破解会不断敲门，我不太推荐。

我更推荐用设备组网工具，比如Tailscale。它可以把手机、电脑、平板装进同一个私有网络，无论你在家还是在出差，访问手机上的服务就像在局域网里一样方便，而且默认不开放公网端口，安全性高一个量级。

安装方式很简单，Debian容器里执行官方脚本，然后浏览器登录设备即可：

curl -fsSL https://tailscale.com/install.sh | sh tailscale up

如果你偏好自托管、不想依赖第三方服务，也可以用frp配合一台有公网IP的云服务器，但需要考虑自己维护认证和加密的成本。对大多数人来说，设备组网工具是更省心的选择。

5. 让手机7×24小时稳定运行，你必须知道的五个坑

很多人的旧手机项目，第一周跑得欢，第二周就开始各种抽风：设备重启、服务失联、温度飙升。这些坑我在过去几个月里基本踩了个遍，整理成五条最重要的经验。

5.1 电池与供电：不要让电池在满电状态下持续充电

手机当服务器使用，最大的物理隐患是电池。持续插电满电运行，锂离子电池的寿命会迅速衰减，还可能鼓包，存在安全风险。

我的做法分几种，按风险从低到高推荐。

第一种，软件层面限制充电电量。部分手机系统自带的电池保护模式只能限制到80%或85%，如果系统没有这功能，可以安装AccA这类充电管理应用（需要root），把充电上限设为60%-80%之间。把手机电量控制在长期偏低的区间，电池衰减速度会慢很多。

第二种，加一个智能插座，设定定时通断，比如每充电两小时断电一小时，让电池有放电循环，不至于一直处于浮充状态。

第三种，如果手机已经插电使用了很久，或者电池本来已经老化，可以考虑扣除电池直接供电。这属于硬件改装，需要懂一点电路知识，风险自负。我的建议是：非专业人士不要碰第三种，前两种已经能覆盖绝大多数需求。

5.2 散热：把旧手机放在它该待的地方

旧手机被动散热能力强于大多数人想象，但长时间满载运行，骁龙这类芯片的发热还是能把后盖烤到40多度。高温会让CPU降频，服务响应变慢，严重时甚至导致系统崩溃重启。

散热方案按投入成本排列：

• 放置位置选在通风良好的架子上，不要放进抽屉或柜子里，更不要放在床上被子旁边。
• 用普通的手机散热背夹或者USB小风扇对着背部吹，效果很直接，能压住好几度。
• 有动手能力的，可以把手机后盖拆下来，加一个石墨烯导热贴片或铝散热片，散热效果提升明显。

我自己的做法是：一台旧的荣耀手机直接拆了后盖，贴上一块铝制散热片悬空放置在开放式置物架上。实测连续跑了两周高负载任务，核心温度一直稳定在65度以下。

5.3 网络稳定性：把Wi-Fi的策略管起来

Android系统默认有一些Wi-Fi省电策略，锁屏后可能会收缩扫描频率甚至暂时断网。指望默认配置下手机能整夜稳定在线是不现实的。要做两件事：

第一，在Wi-Fi设置里对当前网络开启"保持连接"，不同厂商名称不一样，但基本都在高级选项里。第二，把手机插电供电，很多系统会在电量充足时更激进地省电，插电状态下反而更能容忍后台常驻，部分高性能模式也只在插电时才解锁。

如果设备支持USB转以太网，并且你的手机内核有对应驱动，那么USB网卡会是最稳的选择。不过这个方案兼容性参差不齐，而且需要额外购买OTG网卡，我把它定位为"折腾进阶选项"，不是必做项。

5.4 保活与自愈：抗住系统杀进程

后台被杀、服务挂了、SSH失联，这些是手机当服务器最大的日常困扰。除了在系统设置里把Termux设为"不受限制"外，建议再增加一层自愈机制。

在Debian容器里配置一个简单的健康检查脚本，每5分钟检查一次关键服务，如果某个服务没有响应，就自动拉起：

#!/bin/bash services=("sshd" "adguardhome" "aria2c") for svc in "${services[@]}"; do if ! pgrep -f "$svc" > /dev/null; then echo "$(date) restart $svc" >> /var/log/service_guard.log systemctl start "$svc" 2>/dev/null || nohup "$svc" >/dev/null 2>&1 & fi done

然后用crontab定时跑这个脚本：*/5 * * * * /opt/scripts/watchdog.sh。

在Android层，Termux里也可以配合Termux:Widget做一个一键重置脚本，万一SSH真的断了，至少还能在手机上点一下恢复。

5.5 数据安全：旧手机也要有备份意识

旧手机变成服务器后，它上面的数据可能比你想的更值钱。智能家居的自动化流程、DNS过滤规则、下载列表，这些都是长期积累的配置。如果手机硬盘突然挂了，没有备份就真的全没了。

我的备份策略非常简单但有效：

• 配置文件目录每天同步到一个网盘或NAS目录，用rsync或Syncthing。
• 下载目录因为是任务数据，一般不需要备份，但要注意存储空间规划。
• 每台手机在装好环境后，保留一个当时状态的镜像备份或至少记录所有安装包的列表，方便以后重装。

有一个细节：proot环境里的文件默认存放在：/data/data/com.termux/files/usr/var/lib/proot-distro/installed-rootfs/debian/备份时把这个目录整个拷贝走，相当于备份了整个Linux系统。

6. 从一台到一窝：闲置手机算力池的想象力

当你成功让第一台手机稳定跑起来，已经超越了大多数人。接下来更大的乐趣，是让第二台、第三台手机也加入体系，形成一个真正意义上的家庭"算力池"。

6.1 分工模式：每台手机负责一个领域

最简单有效的组织方式，是按职责分工，拒绝所有手机跑一样的环境。我的三台手机就是这种模式：

• 第一台：纯网络基础设施，AdGuard Home + Tailscale，做全屋DNS和远程组网。
• 第二台：下载和文件类任务，aria2 + 文件同步服务。
• 第三台：计算和AI类任务，llama.cpp + Node-RED智能家居自动化。

这样做的好处是故障域隔离。某一台手机出问题，其他服务完全不受影响，不要试图在一台旧手机上塞进所有功能，那样只会让单点故障波及所有服务，而且内存和存储也不够分。

6.2 轻量任务队列：把多台手机组织成分布式执行器

当用户有多个任务要分发时，比手动分配更优雅的方案是搭一个轻量任务队列：一台手机作为master跑调度任务，其他手机作为worker连接队列，各自消费任务、回报结果。

实现方式有很多种。最轻量的方案是：

• 在master上用Redis或NATS做消息队列。
• 各worker跑一个简单的Python脚本，订阅对应的topic，收到任务就执行并回报。
• 使用同一个局域网或Tailscale网络，所有设备节点互通。

这种"分布式任务执行器"虽然不如大型集群专业，但对于"批量图片压缩""批量转码""定时爬虫抓取"这类场景，已经非常实用了。我有一台手机专门负责定时批量转储NAS上的视频文件，压缩完自动移到归档目录，全程不占用主电脑资源。

6.3 进阶玩法：K3s边缘集群

对真正想折腾的玩家，还有个更"硬核"的方向：在手机上跑K3s，组成一个迷你Kubernetes集群。K3s是专为边缘场景设计的轻量Kubernetes发行版，可以在资源受限的设备上运行。

这个方案算力要求高，建议内存至少6GB起步，而且每个节点都要有相对稳定的系统环境。proot环境跑K3s可行但曲折，需要忍受额外的性能损耗，建议尝试路线B或者路线C，把手机刷成原生Linux后跑起来才会比较顺畅。

说实话，我自己也还在折腾这条路。手机K8s集群的工程价值可能有限，但它对理解容器编排、调度、网络和存储这些概念很有帮助。你要是有几台配置不赖的旧手机，不妨拿它当个大型实验玩具。

6.4 "消费级边缘计算"的真正意义

站在更宏观的角度看，手机算力池这件事代表的是一种思路转变：不再把它当成是"淘汰的电子产品"，而是把它当成一个个边缘计算节点。每个家庭其实都有几块闲置算力，只要愿意花心思把它激活，可能就不需要那么多云端付费服务了。

这个思路放在"算力芯生"这个标题下特别贴合——芯片的算力没有消失，只是换了一种存在形式。它可能不再负责点亮屏幕、加载游戏，但通过重新部署，它能继续守护你的网络、管理你的家、整理你的文件、推理你的模型。这种重新定义价值的乐趣，比单纯卖几十块钱废品要有意义得多。

最后再说几句实在话

折腾旧手机这段时间，我最大的感悟是：不要高估算力，也不要低估一台角落里旧手机的能力。它不会成为你又一个吃灰的战利品，而是真正能把手边的"废物"变成"算力"的起点。关键是要选对任务，做好散热和保活，再有耐心调整几次，就能换来一台安静、低成本、全天候在线的私有服务器。

如果你手头恰好也有一台旧手机，不妨就从AdGuard Home或者Node-RED开始。第一次看到手机上那个终端跑起一个对外提供服务的进程时，那种"它重获新生"的感觉，很难用语言形容。希望这篇内容能帮你少踩几个坑，早一点把你的"芯"唤醒。