mikusa | 初之音的 RSS 预览

Docker 部署备忘录

2025-07-28 18:27:00

记录一下在用或用过的一些 Docker 程序，方便下次需要的时候复制粘贴。

这里把重复使用的变量写成了 .env 配置项，将其放在 compose.yml 同路径即可生效，可以在需要变更的时候批量修改。

PUID=1000
PGID=1000
TZ=Asia/Shanghai
NETWORK=caddy

另外，使用 Caddy 或 Nginx 配置反向代理时，可以直接利用 docker 内网寻址的方式获取容器地址。因此默认注释掉了端口映射，有需要的话可以自行开启。

外部网络使用以下命令创建，例如创建一个名为 caddy 的网络：

docker network create caddy

然后需要在 compose.yml 文件末尾指定这个网络，例如：

networks:
  caddy: 
    external: true

文件

h5ai

h5ai 是个我年轻的时候比较流行的 PHP 文件列表程序，现在有容器版本倒是方便了不少。因为 h5ai 需要开启很多 PHP 环境变量，似乎现在比较少见到大家用这个了。以前还有过内置 Dplayer 的版本。

Github：https://github.com/awesometic/docker-h5ai

h5ai is a modern file indexer for HTTP web servers with focus on your files. Directories are displayed in a appealing way and browsing them is enhanced by different views, a breadcrumb and a tree overview. Initially h5ai was an acronym for HTML5 Apache Index but now it supports other web servers too.

h5ai 是一款现代化的 HTTP Web 服务器文件索引器，专注于您的文件。目录以美观的方式呈现，并通过不同的视图、面包屑导航和树形概览增强了浏览体验。h5ai 最初是 HTML5 Apache Index 的缩写，但现在也支持其他 Web 服务器。

另外 h5ai 还有很多可自定义的配置项，有需要请参考：《H5AI 部署、配置与美化》。

services:

  h5ai:
    image: awesometic/h5ai
    container_name: h5ai
    # ports:
    #   - 80:80
    environment:
      - TZ=${TZ}
      - PUID=${PUID}
      - PGID=${PGID}
    volumes:
      - ./h5ai:/config
      - /your/shared/dir:/h5ai
    restart: unless-stopped
    networks:
      - ${NETWORK}

File Browser

File Browser 要比 h5ai 强悍许多，不仅可以直接编辑文件、创建分享链接，还支持多用户。功能上更接近「个人云盘」，因此可以当作轻量云盘使用。

Github：https://github.com/filebrowser/filebrowser

File Browser provides a file managing interface within a specified directory and it can be used to upload, delete, preview and edit your files. It is a create-your-own-cloud-kind of software where you can just install it on your server, direct it to a path and access your files through a nice web interface.

File Browser 可以在指定目录中提供文件管理界面，支持上传、删除、预览和编辑文件。它是一款类似于 “个人云盘” 的软件，您只需将其安装在服务器上，指定路径，然后即可通过美观的 Web 界面访问文件。

我这里的配置和官方有些许不同。官方需要挂载两处文件，而我统一挂载为 /config 。

services:

  filebrowser:
    image: filebrowser/filebrowser:s6
    container_name: filebrowser
    volumes:
      - ./config:/config
      - ./srv:/srv
    environment:
      - TZ=${TZ}
      - PUID=${PUID}
      - PGID=${PGID}
    # ports:
    #   - "80:80"
    restart: unless-stopped
    networks:
      - ${NETWORK}

只是需要在 /config 文件夹中手动创建两个文件。一个是数据库文件 filebrowser.db ，另一个则是 settings.json：

{
  "port": 80,
  "baseURL": "",
  "address": "",
  "log": "stdout",
  "database": "/config/filebrowser.db",
  "root": "/srv"
}

如果对 root 根目录的路径有自定义的需求，可以在 settings.json 中修改，只是相应地也要修改挂载的路径，不要忘了。

Cloudreve

Cloudreve 和前面俩不一样，是真正意义上的云盘，可以通过多种存储策略构建兼备自用或公用的网盘服务。存在付费功能，但个人版够用。

Github：https://github.com/cloudreve/Cloudreve
文档：https://docs.cloudreve.org/zh/

☁️ 支持本机、从机、七牛、阿里云 OSS、腾讯云 COS、华为云 OBS、又拍云、OneDrive (包括世纪互联版) 、S3 兼容协议作为存储端

📤 上传/下载支持客户端直传，支持下载限速

💾 可对接 Aria2 离线下载，可使用多个从机节点分担下载任务

📚 在线压缩/解压缩、多文件打包下载

💻 覆盖全部存储策略的 WebDAV 协议支持

👩‍👧‍👦 多用户、用户组、多存储策略

🔗 创建文件、目录的分享链接，可设定自动过期

🌈 ... ...

在没有配置数据库的情况下，Cloudreve 会使用 SQLite 存储数据。但 SQLite 不支持高并发，官方建议在生产环境中使用其他数据库。

同时，Cloudreve 支持使用 Redis 作为键值缓存，但 Redis 不是必须的，在没有配置 Redis 的情况下，Cloudreve 会使用内存缓存，并在正常退出前将内存缓存的数据持久化到 cache_persist.bin 文件中。

另外，虽然官方文档写着「其中默认包含并启用了 Aria2」，但我没找到 Aria2 相关的配置，比如后台秘钥。

因此，下面的 compose.yml 增加了 Aria2 容器，配置了 PostgreSQL 数据库，并将 Cloudreve 和 Aria2 的下载目录映射至同一路径。

services:
  cloudreve:
    image: cloudreve/cloudreve:latest
    container_name: cloudreve
    depends_on:
      - postgresql
      - redis
    # ports:
    #   - 5212:5212
    environment:
      - CR_CONF_Database.Type=postgres
      - CR_CONF_Database.Host=postgresql
      - CR_CONF_Database.User=cloudreve
      - CR_CONF_Database.Name=cloudreve
      - CR_CONF_Database.Port=5432
      - CR_CONF_Redis.Server=redis:6379
    volumes:
      - ./cloudreve:/cloudreve/data
      - ./downloads:/downloads
    restart: unless-stopped
    networks:
      - ${NETWORK}


  postgresql:
    image: postgres:latest
    container_name: postgresql
    environment:
      - POSTGRES_USER=cloudreve
      - POSTGRES_DB=cloudreve
      - POSTGRES_HOST_AUTH_METHOD=trust
    volumes:
      - ./postgresql:/var/lib/postgresql/data
    restart: unless-stopped
    networks:
      - ${NETWORK}
      
  aria2:
    image: p3terx/aria2-pro
    container_name: aria2
    # ports:
    #   - 6888:6888
    #   - 6888:6888/udp
    volumes:
      - ./downloads:/downloads
      - ./aria2:/config
    environment:
      - TZ=${TZ}
      - PUID=${PUID}
      - PGID=${PGID}
      - RPC_SECRET=your_secret_here
    restart: unless-stopped
    networks:
      - ${NETWORK}
      

  redis:
    image: redis:latest
    container_name: redis
    volumes:
      - ./redis:/data
    restart: unless-stopped
    networks:
      - ${NETWORK}

Zfile

ZFile 是一个基于 Java 的在线网盘程序，功能上大体和 Cloudreve 类似，不过不支持离线下载。

Github：https://github.com/zfile-dev/zfile
官网：https://www.zfile.vip/

支持 S3 协议, 阿里云 OSS, FTP, 华为云 OBS, 本地存储, MINIO, OneDrive 国际/家庭/个人版/世纪互联版/SharePoint, , 七牛云 KODO, 腾讯云 COS, 又拍云 USS.

支持文件操作：上传、下载、重命名、删除、新建文件夹等

图片画廊模式，且支持自定义列数，间距等信息。

文件/文件夹加密、隐藏

目录 readme 文档

支持在线浏览文本文件、PDF、图片、音乐、视频(支持 mp4、flv、hls)

文件直链和二维码

同时挂载多个存储策略

services:

  zfile:
    image: zhaojun1998/zfile:latest
    # ports:
    #   - 8080:8080
    volumes:
      - ./db:/root/.zfile-v4/db
      - ./logs:/root/.zfile-v4/logs
    restart: unless-stopped
    container_name: zfile
    networks:
      - ${NETWORK}

Caddy

Caddy 也能快速搭建一个文件管理列表出来，对于只是浏览和下载来说非常方便，界面也比较美观。

只需要在反代的时候加上 file_server browse，例如：

example.com {
    encode zstd gzip
    root * /home/wwwroot/file
    file_server browse
}

同步

Syncthing

Syncthing 是一个全平台的同步工具，可以在两台或多台设备之间即时同步文件，保证文件的一致性。

Github：https://github.com/syncthing/syncthing
官网：https://syncthing.net/
第三方镜像文档：https://hub.docker.com/r/linuxserver/syncthing

Syncthing is a continuous file synchronization program. It synchronizes files between two or more computers. We strive to fulfill the goals below. The goals are listed in order of importance, the most important ones first.

Syncthing 是一款持续文件同步程序 。它可以在两台或多台计算机之间同步文件。我们致力于实现以下目标。这些目标按重要性排序，最重要的放在最前面。

这里使用的是 LinuxServer.io⁠ 的镜像。另外由于 Syncthing 连接的需求，需要映射 22000 端口。

services:
  syncthing:
    image: linuxserver/syncthing:latest
    container_name: syncthing
    # hostname: syncthing #optional
    environment:
      - TZ=${TZ}
      - PUID=${PUID}
      - PGID=${PGID}
    volumes:
      - ./config:/config
      - ./data:/data
    ports:
    #   - 8384:8384
      - 22000:22000/tcp
      - 22000:22000/udp
      - 21027:21027/udp
    restart: unless-stopped
    networks:
      - ${NETWORK}

监控

Uptime Kuma

Uptime Kuma 是一款易于使用的自托管监控工具。

Github：https://github.com/louislam/uptime-kuma

Monitoring uptime for HTTP(s) / TCP / HTTP(s) Keyword / HTTP(s) Json Query / Ping / DNS Record / Push / Steam Game Server / Docker Containers

监控 HTTP(s) / TCP / HTTP(s) 关键字 / HTTP(s) Json 查询 / Ping / DNS 记录 / 推送 / Steam 游戏服务器 / Docker 容器的正常运行时间

Notifications via Telegram, Discord, Gotify, Slack, Pushover, Email (SMTP), and 90+ notification services, click here for the full list
通过 Telegram、Discord、Gotify、Slack、Pushover、电子邮件 (SMTP) 和 90 多种通知服务发送通知

Multi Languages

多语言

Multiple status pages

多个状态页面

不过 uptime-kuma 包含 Chromium，不仅占空间，还吃内存，需要一定配置的设备运行。

services:

  uptimekuma:
    image: louislam/uptime-kuma:beta
    container_name: uptimekuma
    volumes:
      - ./uptimekuma:/app/data
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - TZ=${TZ}
    restart: unless-stopped
    networks:
      - ${NETWORK}

Nezha

开源、轻量、易用的服务器监控与运维工具。

Github：https://github.com/nezhahq/nezha
官方文档：https://nezha.wiki/

一键安装：支持一键安装面板和监控服务，操作便捷。兼容主流系统，包括 Linux、Windows、macOS、OpenWRT 以及群晖。

实时监控：支持同时监控多个服务器的状态，提供历史网络状态和延迟图表，监控网页、端口可用性和 SSL 证书状态。支持故障和流量等状态告警，可通过 Telegram、邮件、微信等多种方式提醒。

轻松运维：提供 API 获取服务器状态，支持WebSSH、DDNS 和流量监控。可设置定时和触发任务，并批量执行服务器任务。

可以不用脚本安装面板端：

  nezha:
    image: ghcr.io/nezhahq/nezha
    container_name: nezha
    volumes:
      - ./nezha:/dashboard/data
    environment:
      - TZ=${TZ}
    # ports:
    #   - "8008:8008"
    restart: unless-stopped
    networks:
      - ${NETWORK}

参考官方文档使用 Nginx 反代即可用 443 端口连接。需要在面板后台设置中勾选「Agent 使用 TLS 连接」，「Agent对接地址」填写「域名:端口」，例如 example.com:443 ，然后就可以在安装监控端的时候正常连接了。

信息

RSSTT

基于 Telegram 机器人创建的 RSS 通知。利用通讯工具的即时属性，可以用来订阅某些重要的通知。

Github：https://github.com/Rongronggg9/RSS-to-Telegram-Bot

这里只列出了必须的环境变量，其他变量如有需求请自行参考官方文档。

services:

  rsstt:
    image: rongronggg9/rss-to-telegram:dev  # stable image: rongronggg9/rss-to-telegram
    container_name: rsstt
    volumes:
      - ./data:/app/config
    environment:
      - TOKEN=xxxx  #访问 @BotFather 获取
      - MANAGER=xxxx  # 访问 @userinfobot 获取，使用;分隔多用户。例如 1234567890;987654321
# ↓------ To disable sending via Telegraph, comment out this area ------↓ #
# 访问以下链接获取 Telegraph API access tokens: https://api.telegra.ph/createAccount?short_name=RSStT&author_name=Generated%20by%20RSStT&author_url=https%3A%2F%2Fgithub.com%2FRongronggg9%2FRSS-to-Telegram-Bot
# 刷新页面即可获取新的 token，如果你有一堆订阅，请至少使用5个token 
#                            ↓ Replace with your access tokens ↓
      - TELEGRAPH_TOKEN=
        xxx
        xxx
      - MULTIUSER=1  #多用户模式，0关闭，1启用，默认为1
      - TZ=${TZ}
    restart: unless-stopped
    networks:
      - ${NETWORK}

RSSHub

万物皆可 RSS，世界上最大的 RSS 网络。

由于配置了 browserless，因此 RSSHub 非常吃配置，需要部署在稍微给力点的机子上。

services:

  rsshub:
    image: diygod/rsshub:latest
    container_name: rsshub
    # ports:
    #   - '1200:1200'
    environment:
      - NODE_ENV=production
      - CACHE_TYPE=redis
      - REDIS_URL=redis://redis:6379/
      # - PIXIV_REFRESHTOKEN=
      # - PIXIV_IMG_PROXY=
      # - PIXIV_BYPASS_DOH=https://dns.google/dns-query
      # - PIXIV_BYPASS_CDN=true
      - PUPPETEER_WS_ENDPOINT=ws://browserless:3000  # marked
      # - PROXY_URI='socks5h://warp-socks:9091'
    restart: unless-stopped
    depends_on:
    #   - redis
      - browserless
    networks:
      - ${NETWORK} 

  browserless:  # marked
    image: browserless/chrome  # marked
    container_name: browserless
    restart: unless-stopped  # marked
    ulimits:  # marked
      core:  # marked
        hard: 0  # marked
        soft: 0  # marked
    networks:
      - ${NETWORK}

FreshRSS

自托管 RSS 信息流聚合器。

Github：https://github.com/FreshRSS/FreshRSS

这里使用的是 LinuxServer.io⁠ 的镜像，另外配置了两个插件。时间久远我也不记得这俩咋用了，如有需要请自行研究。

services:

  freshrss:
    image: linuxserver/freshrss:latest
    container_name: freshrss
    # ports:
    #   - 80:80
    volumes:
      - ./config:/config
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - CRON_MIN=*/20
    logging:
      options:
        max-size: 10m
    restart: unless-stopped
    networks:
      - ${NETWORK} 

  read:
    image: phpdockerio/readability-js-server
    container_name: read
    restart: unless-stopped
    networks:
      - ${NETWORK} 

  merc:
    image: wangqiru/mercury-parser-api
    container_name: merc
    restart: unless-stopped
    networks:
      - ${NETWORK}

工具

Vaultwarden

自托管密码管理器。

Github：https://github.com/dani-garcia/vaultwarden

services:

  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    volumes:
      - ./data:/data
    environment:
      - WEBSOCKET_ENABLED=true
      # - ADMIN_TOKEN=
      - SMTP_HOST=
      - SMTP_FROM=
      - SMTP_PORT=
      - SMTP_SECURITY=starttls
      - SMTP_USERNAME=
      - SMTP_PASSWORD=
      - SMTP_AUTH_MECHANISM="Login"
      - DOMAIN=https://
      - SIGNUPS_ALLOWED=false
    restart: unless-stopped
    networks:
      - ${NETWORK}

Nazurin

帮助你从各种网站收集 ACG 插画的 Telegram 机器人。

这个工具对于我这种收图党来说非常好用，有空水一下用法。

Github：https://github.com/y-young/nazurin/
官方文档：https://nazurin.readthedocs.io/zh/

services:
  nazurin:
    image: ghcr.io/y-young/nazurin:latest
    container_name: nazurin
    user: ${PUID}:${PGID}
    # build: .
    env_file:
      - ".env"
    volumes:
      - ./data:/app/data
      - ./Nazurin:/Nazurin
    # ports:
    #   - "80"
    environment:
      - TZ=${TZ}
    restart: unless-stopped
    networks:
      - ${NETWORK}

由于包含了所有存储配置，默认的环境变量非常长。如果你像我一样也将图片保存在本地，且服务不想对外，可以试试这么写：

# 访问以下链接获取更多信息：https://nazurin.readthedocs.io/getting-started/configuration/

# ---------- Required ----------
# Telegram bot token
TOKEN = xx

# 默认选项（production）使用 Webhook 模式，你可以设置为 development 以使用轮询模式。
ENV = development

# 发送到 Telegram 服务器的 Webhook URL，机器人的服务器应能通过此 URL 访问，应以 / 结尾，例如 https://xxx.fly.dev/。
# 如使用 Webhook 模式则必需
# WEBHOOK_URL = 

# 要绑定到的主机地址，默认为 0.0.0.0。使用反向代理时请设置为 127.0.0.1。
# 如使用 Webhook 模式则必需
HOST = 0.0.0.0

# Webhook 端口，使用 Heroku 时自动设定。
# 如使用 Webhook 模式则必需
PORT = 8080

# 存储类型
STORAGE = Local

# 数据库类型
DATABASE = Local

# 管理员用户的 Telegram 用户 ID（不是用户名），机器人的一些功能仅限管理员用户使用。
ADMIN_ID = xx

# ---------- Optional ----------
# 本地或远程存储的目录路径，如不存在则自动创建。
STORAGE_DIR = /Nazurin

# 同时下载的最大文件数。
MAX_PARALLEL_DOWNLOAD = 6

# 临时目录清理的间隔时间，单位为天。每次清理时将删除访问时间在一天前的文件。设置为 0 时将禁用自动清理。
CLEANUP_INTERVAL = 7

# 图片收藏成功后的反馈方式，可选值如下：
# reply：回复原消息
# reaction: 在原消息上添加表情回应
# both：回复并添加表情回应
FEEDBACK_TYPE = reaction

# ---------- 站点 ----------

# ----- Bilibili -----
# 存储路径
BILIBILI_FILE_PATH = Bilibili

# 文件名称
# BILIBILI_FILE_NAME = {id_str}_{index} - {user[name]}({user[mid]}) 


# ----- Pixiv 配置项-----
# Refresh token
PIXIV_TOKEN = xx

# 浏览作品时的图片代理，用于帮助 Telegram 服务器更稳定地获取图片，下载作品时仍然会使用 Pixiv 服务器。
# PIXIV_MIRROR = 

# 标签的显示语言，如果没有可用翻译则使用日语原文。默认使用原文，配置值将设置在 HTTP Header 的 Accept-Language 选项中。例如：zh-CN, en-US
PIXIV_TRANSLATION = zh-CN

# 收藏可见性 (public/private)
# PIXIV_BOOKMARK_PRIVACY = public

# 存储路径
PIXIV_FILE_PATH = Pixiv/{user[id]}

# 文件名称
PIXIV_FILE_NAME = {filename}

# ----- Twitter 配置项-----
# 要使用的 API，web 或 syndication。Web API 来自网页应用，而 Syndication API 来自 https://publish.twitter.com。
# Syndication API 无法获取被标记为敏感内容的推文，但如果设置了 TWITTER_AUTH_TOKEN，则可以通过 Web API 获取。
# 当 Web API 不可用时，你可以选择切换到 Syndication API。
TWITTER_API = web

# Web API 的授权令牌
TWITTER_AUTH_TOKEN = xx

# 存储路径
TWITTER_FILE_PATH = Twitter

# 文件名称
TWITTER_FILE_NAME = {id_str}_{index} - {user[name]}({user[id_str]})

其他

gh-proxy-go

gh-proxy 的 Go 语言版本。

Github：https://github.com/Xm798/gh-proxy-go

默认的配置文件 config.json 支持自定义以下选项，挂载 /app/config 即可：

host: 默认 "0.0.0.0"，服务器监听地址

port: 默认 8080，服务器监听端口

whiteList: 允许访问的 GitHub 用户/组织列表，配置后将拒绝所有未在列表中的请求

blackList: 禁止访问的 GitHub 用户/组织列表，配置后将拒绝所有在列表中的请求

forceEnUSForRaw: 默认 false，是否强制使用 en-US 语言访问 raw.githubusercontent.com，以规避中文用户可能的 429 错误

sizeLimit: 默认 10240，文件大小限制（单位：MB）

注意：host 和 port 配置不支持热重载，需要重启服务才能生效。其他配置项支持热重载。

services:
  ghproxy:
    image: xm798/gh-proxy-go:latest
    container_name: ghproxy
    # ports:
    #   - 8080:8080
    # volumes:
    #   - ./ghproxy:/app/config
    environment:
      - TZ=${TZ}
    restart: unless-stopped
    networks:
      - ${NETWORK}

hubproxy

一个轻量级、高性能的多功能镜像服务。

Github：https://github.com/sky22333/hubproxy

services:

  hubproxy:
    container_name: hubproxy
    image: ghcr.io/sky22333/hubproxy
    restart: always
    # ports:
    #   - 5000:5000
    networks:
      - ${NETWORK}

最后

还有啥等想起来再加进来。

关于 Caddy

2025-07-27 18:49:00

最近试着用了下 Caddy，自动申请证书确实非常方便，就是中文文档少了点。虽然官方文档写得很详细，社区里提问也基本有问必答，奈何都是英文，而 I english was very bad。所以这里记录一些使用过程中遇到的问题，以便以后忘了怎么用的时候，不必再跟 AI 大战三百回合。

安装

直接参考 Cyrus 佬的 docker-caddy 就行。如果需要其他模块，参照仓库内的 Dockerfile 修改一下，自己编译一个镜像。

伪静态

Typecho 是 PHP 驱动的博客程序，但可以启用伪静态以优化 URL，不过需要在 Web 服务器上处理一下。如果是 Nginx 的话，是这么写的：

try_files $uri $uri/ /index.html;

而 Caddy 可以直接通过 php_fastcgi 实现 Nginx 的 try_files 效果，不过根据官方文档对于 php_fastcgi 的解释，其实是这个指令自带了一些默认写法，包括 try_files。例如：

    @indexFiles file {
        try_files {path} {path}/index.php index.php
        try_policy first_exist_fallback
        split_path .php
    }

因此配置一个 Typecho 博客的时候，伪静态就可以直接这么写：

example.com {
    encode zstd gzip
    root * /srv/example.com
    file_server
    php_fastcgi php:9000
    header {
        -Server
        -X-Powered-By
    }
}

但是二级目录就行不通了，得手动写一下 try_files 指令。Nginx 是这么写的：

    location /blog/ {
        if (!-e $request_filename) {
            rewrite ^(.*)$ /blog/index.php$1 last;
        }
    }

Caddy 也差不多。假设你的一级域名博客 example.com 放在了 /srv/example.com 这个文件夹中，而这个文件夹里又有个 blog 文件夹打算放另一个博客，即：

example.com {
    encode zstd gzip
    root * /srv/example.com
    file_server
    php_fastcgi php:9000
    handle /blog/* {
        try_files {path} /blog/index.php?{query}
    }
}

注意要保证 /blog/index.php?{query} 前面的 blog 和文件夹名称一致。

然后伪静态就能正常工作了。

日志

参考《一行代码快速配置 Caddy 站点日志——复用 Caddy 配置段》，可以实现使用 Caddy 的代码段（Snippet）和占位符，为每个站点更优雅地配置日志。

但有一个问题是，对于习惯了 Nginx 简短的一行日志的我来说，Caddy 的 JSON 日志并不优雅：

{"level":"info","ts":1753359481.0373497,"logger":"http.log.access.log19","msg":"handled request","request":{"remote_ip":"3.4.5.6","remote_port":"51262","client_ip":"1.2.3.4","proto":"HTTP/2.0","method":"GET","host":"example.com","uri":"/vcb-s","headers":{"Cf-Ipcountry":["US"],"Cdn-Loop":["cloudflare; loops=1"],"Accept":["application/rss+xml, application/rdf+xml, application/atom+xml, application/xml;q=0.9, text/xml;q=0.8, text/*;q=0.7, application/*;q=0.6"],"X-Forwarded-Proto":["https"],"Cf-Connecting-Ip":["1.2.3.4"],"If-None-Match":["\"1138a-MnD/hvrofjXPGRMPTdAYBESwO4U\""],"If-Modified-Since":["Thu, 24 Jul 2025 04:34:01 +0000"],"Cf-Ray":["96435b8e8b406fd7-IAD"],"X-Forwarded-For":["1.2.3.4"],"User-Agent":["RSStT/2.10.0 RSS Reader (+https://git.io/RSStT)"],"Accept-Encoding":["gzip, br"],"Cf-Visitor":["{\"scheme\":\"https\"}"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"example.com"}},"bytes_read":0,"user_id":"","duration":0.926949864,"size":0,"status":304,"resp_headers":{"Via":["1.1 Caddy"],"Access-Control-Allow-Methods":["GET"],"X-Content-Type-Options":["nosniff"],"Date":["Thu, 24 Jul 2025 12:18:01 GMT"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Access-Control-Allow-Origin":["example.com"],"Cache-Control":["public, max-age=300"],"Content-Type":["application/xml; charset=utf-8"],"Etag":["\"1138a-MnD/hvrofjXPGRMPTdAYBESwO4U\""],"X-Rsshub-Route":["/vcb-s"]}}

至少不是人能看的。

我只是写写博客玩，用不上这么详细的日志。一番搜索，发现 Nginx 的日志样式叫做 Common Log Format (通用日志格式)，而 Caddy 有一个模块可以实现这种日志样式。可以在构建镜像的时候自己塞进去：

FROM caddy:builder AS builder

RUN apk add --no-cache tzdata

RUN xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    # --with github.com/caddy-dns/dnspod \
    # --with github.com/caddy-dns/alidns \
    --with github.com/caddy-dns/tencentcloud \
    # Extended plugins
    --with github.com/mholt/caddy-dynamicdns \
    --with github.com/caddyserver/replace-response \
    # 加入日志模块
    --with github.com/caddyserver/transform-encoder

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

然后在原日志代码段加上日志格式化配置：

(log) {
    log {
        output file /log/{args[0]}/access.log {
            roll_size 5MiB
            roll_local_time
            roll_keep 10
            roll_keep_for 2160h
        }
        format transform `{request>remote_ip} - {user_id} [{ts}] "{request>method} {request>uri} {request>proto}" {status} {size} "{request>headers>Referer>[0]}" "{request>headers>User-Agent>[0]}"` {
            time_format "2006-01-02 15:04:05"
            time_local
        }
    }
}

日志就会变成这样：

4.5.6.7 - - [2025-07-25 10:11:37] "GET / HTTP/2.0" 200 1901 "-" "Uptime-Kuma/2.0.0-beta.3"

舒服多了。

~~只是这个模块被官方遗弃了，官方觉得 JSON 日志好使。~~

CA

Caddy 默认的 CA（证书颁发机构）是 Let's Encrypt，但也支持使用其他 CA，比如 ZeroSSL。而我们还可以通过在 Caddyfile 中使用 acme_ca 指令来指定其他 CA，比如 Google。

参考《使用 acme.sh 申请 Google 的免费 SSL 证书》获取 EAB 密钥后，在 Caddyfile 顶部加入以下配置：

    acme_ca https://dv.acme-v02.api.pki.goog/directory
    acme_eab {
        key_id xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        mac_key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    }
    email [email protected]

随后添加域名，重载 Caddy 配置，尝试申请证书。

如果 Caddy 内的 /data/caddy/acme/ 文件夹出现了名为 acme/dv.acme-v02.api.pki.goog-directory 的文件夹，且该文件夹内包含上面注册 ACME 账户时使用的邮箱，即表示账户注册成功。

随后要观察 /data/caddy/certificates/ 是否文件夹出现了 dv.acme-v02.api.pki.goog-directory 文件夹。若该文件夹内部有域名证书生成，则表示证书申请成功。

文件结构大概是像这样：

data
└── caddy
    ├── acme
    │   ├── acme-v02.api.letsencrypt.org-directory
    │   │   └── users
    │   │       └── [email protected]
    │   ├── acme.zerossl.com-v2-dv90
    │   │   └── users
    │   │       └── [email protected]
    │   └── dv.acme-v02.api.pki.goog-directory
    │       └── users
    │           └── [email protected]
    ├── certificates
    │   ├── acme-v02.api.letsencrypt.org-directory
    │   │   └── example.com
    │   │       ├── example.com.crt
    │   │       ├── example.com.json
    │   │       └── example.com.key
    │   └── dv.acme-v02.api.pki.goog-directory
    │       └── example.com
    │           ├── example.com.crt
    │           ├── example.com.json
    │           └── example.com.key
    ├── instance.uuid
    ├── last_clean.json
    ├── locks
    └── ocsp

不过这个 EAB 密钥使用一次后便会自动失效，不使用也会在七天内失效。但使用 EAB 密钥注册的 ACME 帐户没有过期时间，对证书续期没有影响。

所以待 ACME 账户注册成功后，就可以注释或删除相关秘钥，仅保留 acme_ca 配置：

    acme_ca https://dv.acme-v02.api.pki.goog/directory
    email [email protected]

但使用 Google CA 除了能表明证书来自谷歌之外，没有其他优势。追求新鲜玩玩就够了，平常还是用 Let's Encrypt 或 ZeroSSL 比较合适。

~~再说 https://dv.acme-v02.api.pki.goog/directory 也被墙了，国内机子根本没法申请。~~

缓存

Caddy 并不能像 Nginx 一样在反代网站的时候配置缓存，需要手动安装一些模块。比如 cache-handler，一个分布式 HTTP 缓存模块，构建镜像的时候加上它：

FROM caddy:builder AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    # --with github.com/caddy-dns/dnspod \
    --with github.com/caddy-dns/alidns \
    --with github.com/caddy-dns/tencentcloud \
    # Extended plugins
    --with github.com/mholt/caddy-dynamicdns \
    --with github.com/caddyserver/replace-response \
    # 分布式 HTTP 缓存模块
    --with github.com/caddyserver/cache-handler

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

使用倒是很简单：

{
    cache
}

example.com {
    cache
    reverse_proxy your-app:8080
}

具体用法还是得查查相关文档，我不太会用。

但我在琢磨缓存的时候搜到了另一个模块，叫做 cdp-cache。它与 cache-handler 的区别在于，这个模块更容易理解和配置。

一样先构建镜像：

FROM caddy:builder AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    --with github.com/caddy-dns/tencentcloud \
    # Extended plugins
    --with github.com/mholt/caddy-dynamicdns \
    --with github.com/caddyserver/replace-response \
    # 第三方缓存模块
    --with github.com/sillygod/cdp-cache

FROM caddy:latest

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

然后在网站配置中启用：

proxy.example.com {
    reverse_proxy https://example.com
    http_cache {
        cache_type file
        path /cache
        match_path /images
        default_max_age 24h
    }
}

配置项不少，具体得参考官方文档。

~~我玩不来，用了一两天就删掉了。~~

robots.txt

如果有些网站你并不想被爬虫抓取，就可以使用 robots.txt，立下君子协定：

User-agent: *
Disallow: /

这玩意本质上就是个 txt 文本，所以可以在 Web 服务器端直接配置，例如 Nginx：

    location = /robots.txt {
        default_type text/html;
        add_header Content-Type "text/plain; charset=UTF-8";
        return 200 "User-Agent: *\nDisallow: /";
    }

Caddy 也可以这么做，直接在 Caddyfile 中加入 robot_txt 配置块：

(robots_txt) {
    respond /robots.txt 200 {
        body "User-agent: *
Disallow: /"
    }
}

然后在网站配置文件中导入该块：

example.com {
    encode zstd gzip
    root * /srv/blog
    file_server
    import robot_txt
}

IPv6

现在越来越多的服务器厂商开始支持 IPv6，我的服务器也提供了开启 IPv6 的选项。但 IPv6 其实坑不少，至少我不太会用。就比如我一昧追新开启了 IPv6 后，发现博客后台获取不到正确的访客 IP 地址，全部都是内网地址。

~~我甚至以为是 Nginx 的问题，查了半天，才发觉可能是 IPv6 的锅。~~

总之，AI 是这么解释的：

此问题的根源在于 Docker 守护进程未启用 IPv6，导致容器本身不具备原生的 IPv6 网络栈和地址。当外部 IPv6 流量通过端口映射到达宿主机时，Docker 的网络代理层（通常是 docker-proxy 进程或 iptables 规则）必须执行跨协议转发。在此过程中，它会终止原始的 TCPv6 连接，然后以 Docker 网桥的 IPv4 地址（如 172.17.0.1）为源地址，向容器的私有 IPv4 地址发起一个全新的 TCPv4 连接。最终，容器内的 Nginx 服务只能感知到这个新连接的直接来源，即作为代理的 Docker 网关，从而丢失了真实的客户端 IPv6 源地址信息。

所以，如果你的服务器也启用了 IPv6，为了让容器能正常识别来自 IPv6 的访问，请开启 Docker 的 IPv6 支持，并创建一个支持 IPv6 的 Docker 网络。

编辑 Docker 的配置文件（通常位于 /etc/docker/daemon.json），加入或合并以下内容以开启 Docker 的 IPv6 支持：

{
  "ipv6": true,
  "fixed-cidr-v6": "fd00:dead:beef::/48"
}

操作命令：

sudo mkdir -p /etc/docker

sudo tee /etc/docker/daemon.json > /dev/null <<EOF
{
  "ipv6": true,
  "fixed-cidr-v6": "fd00:dead:beef::/48"
}
EOF

重启 Docker 服务以应用更改：

sudo systemctl restart docker

随后创建一个支持 IPv6 的 Docker 网络：

docker network create \
  --driver bridge \
  --ipv6 \
  --subnet fd00:3939::/64 \
  caddy

再把容器加入到这个新建的 caddy 网络即可。

文件访问

在 Nginx 中通常会加上这么个配置：

    location ~ /.well-known {
        allow all;
    }

    location ~ /\. {
        deny all;
    }

前者用于允许路径 /.well-known 下内容的访问¹，后者则是禁止访问以点号开头的隐藏文件（比如 .git、.htaccess、.env 等）。

Caddy 默认会对 /.well-known/acme-challenge 这类路径自动处理，而对于以点开头的隐藏文件，使用 @hiddenFiles 匹配所有路径以 / + 点号开头的请求，再 respond 返回 HTTP 403 禁止访问即可。

@hiddenFiles {
    path_regexp hiddenFiles ^/\..*
}
respond @hiddenFiles 403

塞到网站配置中就能用了：

example.com {
    encode zstd gzip
    root * /srv/blog
    file_server

    @hiddenFiles {
        path_regexp hiddenFiles ^/\..*
    }
    respond @hiddenFiles 403
}

这是一个标准路径，通常用来放置一些公开的、需要被外部访问的文件或信息，比如 Let's Encrypt 证书验证文件（ACME Challenge）、安全政策文件（如 security.txt）、其他协议定义的公开信息文件。 ↩

我从来没有觉得看《Ave Mujica》快乐过

2025-07-15 18:52:00

这次也尝试水一下今年看过的一月番剧的简单吐槽。

BanG Dream! Ave Mujica

还记得两年前的7月，那时《BanG Dream! It's MyGO!!!!!》正热火朝天，可惜我本就对《BanG Dream!》系列一点都不感兴趣，更不用说这《MyGO!!!!!》了。什么「重女」，什么「地雷」，通通与我毫无干系。我只是因为刷到了泛式的视频，再加上大家的口口相传，闲来无事才想着看一两集试试水的。至于用一个下午的时间一口气看到了 10 话，完全是意料之外。虽然不得不承认这种欲罢不能的感觉十分奇妙，就像是便秘了 10 天一口气排干净那般畅快。以至于我不禁怀疑是不是年龄来到了 30 岁之后，连追番取向都发生了改变。

总之，正是因为《MyGO!!!!!》，我才对这类题材番剧的刻板印象有所改观，继而能接受除《轻音少女》和《孤独摇滚》以外的乐队番。后来我又看了《夜晚的水母不会游泳》和《少女乐队的呐喊》，以及《MyGO!!!!!》的续篇：《BanG Dream! Ave Mujica》。

在《MyGO!!!!!》还在热映的时候我便已经非常好奇，丰川祥子退出 CRYCHIC 的原因能否得到完美的解释，三角初华对祥子的不离不弃又是出自何种原因，高松灯和祥子是否能够再续前缘……当然最重要的，还是《MyGO!!!!!》最后一集登台的 Ave Mujica 乐队，会为这个系列带来一段如何「黑深残」的故事。而现在，距离动画完结已经过去了三个多月，我的疑惑也确实得到了「完美」的解答。

祥子退队的原因不难解释。一直接受精英教育的她在经历母亲离世、父亲因故被逐出家门等等一系列变故后，经济和心境上都陷入了空前的困境。曾经优渥的生活和如今挤在三坪小房间里的窘境带来的反差，她已经无法再像往日一样游闲地同乐队伙伴畅谈音乐理想。白天上学、晚上兼职、回家还要面对父亲的冷暴力。这突如其来的一切使她迫不得已选择用最极端、最决绝的方式来斩断过去的生活，包括与 CRYCHIC 的联系。

这也许是她面对巨大生活压力和内心挣扎的一种扭曲的自我保护机制。祥子一直以来都是一个骄傲且自尊心极强的人，即便身边知情的朋友愿意提供帮助，比如比如睦、初华——甚至是下跪的素世，她还是选择独自承受一切，不愿将自己软弱的一面示人。

只不过祥子家庭上的变故早在《MyGO!!!!!》中就已见端倪，多少能从剧情上看出一些猫腻，《Ave Mujica》仅仅是将这些背后的故事搬到台面上了而已。我本以为会有其他出乎意料的解释，没想到是如此现实的原因。于是我又有了新的困惑：既然祥子是因为自身原因才从 CRYCHIC 退队的，那睦为什么要说出「我从来没有觉得玩乐队开心过」这句话呢？

彼时的睦作为配角戏份并不多，她带给观众的一直都是沉默寡言、情绪不外露的文静形象。即便她的艺人家庭背景有稍微展露，也从未提到过她有演戏的才能。反倒是她的「无口」性格可能是由于缺少父母的陪伴、生活氛围过分压抑等家庭因素所导致的。如果连她都觉得在 CRYCHIC 的活动十分压抑，那乐队内部可能早已病入膏肓，分崩离析自然是迟早的事。

单凭这些，我还是觉得无法直接将睦的言行同「演技」挂钩，可编剧就是这么做了。在《Ave Mujica》中我们可以清楚地得知，由于受到艺人家庭的影响，儿童时期的睦就已经表现出远超常人理解的演技天赋。她可以在随时随刻转换情绪，自由地将大家希望看到的一面通过「演技」展示出来。

没有特别复杂的原因，睦就是为了袒护突然退队的祥子，才故意演了一出「好戏」的，只是这么解释明显背离了《MyGO!!!!!》时睦的人设，所以为了合理化这一行为，编剧还强行安排上所谓「双重人格」的设定，以便让一切设定合理自洽。

只是如此一来，CRYCHIC 解散的「病根」就显得有些荒谬了。如果一切都是睦为了给突然退队的祥子而演的一场戏，如果《MyGO!!!!!》中睦的言行完全都是演技，那么 CRYCHIC 的解散就不再是成员之间的真实矛盾，而更像一场人为的闹剧。高松灯所有的挣扎和成长，就都建立在了这样一个虚假的基石之上。

这么做除了把睦的角色搞得更加面目全非、给本就雪上加霜的剧情再浇一盆冷水、使粉丝失望、让路人贻笑大方以外，没有其他意义。

这还不算恶心人，《Ave Mujica》对初华角色的补全，是另一层面的匪夷所思。初华在《MyGO!!!!!》中虽然戏份不多，也算是比较重要的角色。不仅在祥子失落的时候陪伴着她、给予她无微不至的关怀，还在祥子提议组建新乐队的时候积极参与——这是一种近乎无条件的忠诚与爱意。我本以为会深入探讨她与祥子之间那份超越表象的情感，或是揭示她为何能如此坚定地站在祥子身边。但仿佛是要扼杀这一角色一般，编剧全盘否定了初华自身的努力，将她置于一个非常低贱的地位，把她的所作所为全部归结为对祥子的「报恩」。

故事讲到这里，我已经不再关心《Ave Mujica》能否再续《MyGO!!!!!》的高光，也不在意祥子会不会在 Ave Mujica 中解开心结，更无所谓「黑深残」会发展成什么样的结局。因为真正在意这个「过家家乐队」生死存亡的，只有不知为何将自己绑定在 Ave Mujica 的海铃，和想借机炒红自己的瞄梦。

这下我是真的没有觉得看《Ave Mujica》快乐过了。

在冲绳喜欢上的女孩方言讲得太过令人困扰

去年有部叫做《北海道辣妹贼拉可爱》（以下简称《北海道辣妹》）的冬季新番，试着追了两集，主要讲述因父母工作而从东京来到北海道上学的「京爷」邂逅本地辣妹的故事。可惜剧中的辣妹既不可爱，剧情也不过是老套的「党争」——京爷被一群辣妹包围，唯一的新鲜感不过是这群辣妹来自北海道。结果就是，《北海道辣妹》压根没吸引到我不说，反而让我对此类标题带地域标签的动画产生了条件反射式的排斥。于是在看到《在冲绳喜欢上的女孩方言讲得太过令人困扰》（以下简称《冲绳妹》）的时候，才直接给它打上了「烂片预定」的标签。幸亏忙里偷闲看了两集，才没有错过这部带有浓厚地域文化的恋爱喜剧。

虽然《冲绳妹》也是以东京男主角跟随父亲转学到小岛冲绳恋上本地黑皮妹而展开的故事，但和《北海道辣妹》有本质上的不同，《冲绳妹》的故事核心在于介绍冲绳独特的地方风俗和民族文化。诙谐的单元叙事结构加上可爱的双女主，通过角色日常生活的方方面面以及各种小细节，配合穿插的各种 neta，自然地融入那些冲绳本地人习以为常、但是外来人从没接触过的梗和笑料，使得这部「地方宣传片」在观感上极为舒适。

不过我最关注的当然还是恋爱。男主角「中村照秋」在开学第一天就被冲绳土著「喜屋武飞夏」搭话，阳光开朗的飞夏在他眼里闪闪发光，照秋因此对飞夏一见钟情。但照秋听不懂冲绳方言，飞夏也不会说标准日语。两难之际，飞夏的闺蜜「比嘉夏菜」及时站了出来，充当翻译将飞夏说的话转述给了照秋。此后每逢飞夏与照秋对话，夏菜都在场担任双方的「传话筒」。

其实早在男主初次来到冲绳的时候就遇见了夏菜，夏菜因为男主小小的帮助而对他暗生情愫，在见到照秋转学来冲绳更是高兴的不行。没错！我爱看的就是这种三角结构！照秋希望能多了解些冲绳文化好接近飞夏，大大咧咧的飞夏对此浑然不知，于是三角的重心就集中到了内敛的夏菜身上。那压抑不住的情感常常溢于言表，厚重的刘海和假装冷静的外表下遮掩不住的是只有男主才发现不了的炽热少女心。尤其是黝黑的皮肤透出的点点红晕，配合青春期少女娇羞的小心思，冲着这画面我能吃下三碗饭！

续集

其他续集就不知道怎么写了。这个一月还看了《超超超超超喜欢你的100个女朋友第二季》，《我独自升级》两季，加上上面两部，总共看了4部新番。《100女友》可能没有第一季那么让人眼前一亮，却也是非常棒的后宫作品；《我独自升级》属于快节奏的装逼系列，因为 A1 制作给力，我甚至把漫画也看了个七七八八，可能没什么营养，但胜在快乐。

备用机的养成方法

2025-06-18 16:38:00

「备用机」，顾名思义，是指以备不时之需的手机。它可以是一部只能收发短信、拨打电话、玩玩贪吃蛇的诺基亚，也可以是陪你走过青春岁月的老朋友小米 6；它可以是功能齐全但电池健康度只剩 50%、Face ID 罢工的 iPhone X，也可以是一部崭新出厂、配备 1TB 存储的豪华版小米 15S Pro。

但又不可与「副机」混为一谈。有些人本就习惯双持，一部工作用，一部生活用，或者 iPhone 和 Android 各一部。这类情况当属日常配置，不能算作备用机的范畴。

如果你正好有一部闲置的手机，那它自然可以充当「备用机」的角色。可更多时候，备用机是自己或家人换下来的老旧机型。就比如我目前使用的是一部搭载火龙 888 处理器、~~由雷军亲手焊接的~~ 迟迟没有烧掉 WiFi 的小米 11。

可假如你就只有一部手机，需要另一部手机备用，该怎么选择才合适呢？或者说，合格的备用机该具备哪些品质，才能担起「临危受命」的重任呢？

挑选

根据个人财力和需求上的不同，备用机的选择自然是五花八门。对我来说，最实用的备用机必须是一部能解锁 Bootloader 的安卓机器。因为解锁之后，它就可以做到：

获取 ROOT 权限：任意安装各种各样功能强悍的应用，Magisk、Shizuku、Lsposed、GKD……
掌控应用权限：比手机管家更激进的权限管控，再也不怕 APP 到处拉屎；
精简系统应用：无用应用全部冻结，垃圾软件统统干掉。

甚至还能当一台 Always Online 的小型 Linux 终端。如果机身存储空间够大，把它当作影音服务器也不是不可能¹。就是这么玩就有点太硬核了，毕竟不是所有人都知道「解锁」是个什么概念，也不是所有人都会这么压榨手机，更不会把心思都花在备用机上。

因此我们还是回到常规角度，从备用机的自身建设和基础功能等方面出发。我认为有以下几点：

稳定

备用机，说白了就是需要的时候能派上用场，其余的时间都在隐秘的角落独自落泪。因此哪怕不是最新最强，也得是台「关键时刻不掉链子」的机器：能正常开机、联网，不会间歇性重启，就已经赢了一半；若是有还算能看的流畅度，那就赢下了另一半。

~~如果还能玩玩原神星铁，那就可以顺理成章地坐上副机的宝座。~~
续航

虽然大部分时间都躺在抽屉里吃灰，但真到要用的时候，总不能刚点亮屏幕就提醒你「电量不足，还有 30S 关机」吧？因此电池健康度方面最好别太离谱。

可话又说回来，如果你跟我一样，愿意让备用机全年 365 天 24 小时插着电，那电池拉胯也就不是什么问题了。我的小米 11 尽管电池健康已经跌到 60%，日常使用都力不从心，可它早已退居二线，干脆当成「插电设备」使，也算是变废为宝，顺便还能省下一笔换电池的钱。
便宜

毕竟是备用机，不追求极致体验，但求在预算范围内堪用。

~~但如果你的预算高到了一定程度，稳定和续航就不是问题了。所谓「三千预算进卡吧，加钱加到九万八」，在手机这边也是相同的道理。~~

显然，功能机在这方面有天生的优势，但只能打电话发短信的话，这备用机未免太鸡肋了点。另外，iPhone 也不作详细推荐。虽然每一代 iPhone 都具备成为优秀备用机的潜力，但其选择逻辑和安卓不尽相同。简单来说，如果需要双卡双待，选择 iPhone 11 或更新的国行版本；如果偏爱小屏，iPhone 13 mini 是个不错的选择。再加上 iOS 系统的封闭性，其可定制和折腾的空间相对较小，iPhone 的使用寿命也比 Android 要长得多。因此，本文的备用机选择主要还是针对安卓设备展开。

所以，在处理器方面，尽量避开某些采用高发热处理器的设备，例如骁龙 888 和骁龙 8 Gen 1。因此，可以优先考虑 2022 年之后发布、且搭载了后续型号处理器的手机。如果考虑更早发布的旧款型号，骁龙 865 是个不错的选择；假如预算更低，骁龙 845 也可以考虑，但性能和功耗表现会逊色一些。此外，联发科近两年的天玑系列，如天玑 8100、天玑 9000 等，也是公认的「口碑之选」。

对于操作系统，国内安卓设备无非就是 HMOV。是选择华为、小米、OPPO 还是 vivo，主要取决于个人偏好。根据我的 个人经验，华为（包括荣耀）的内置广告和预装软件最多，OPPO（我只用过一加）也有不少广告，且不支持关闭；小米虽然系统广告大多可以手动关闭，但其 HyperOS（或 MIUI）有时会遇到一些难以预料的小问题。

至于屏幕、摄像头、存储容量等等就看个人需求了。~~实在拿不定主意，再买一台和主力机一模一样的机器也不是不行。~~

养成

OK。假设你已经按照上面的思路，挑选到了一台心仪的备用机。但这还只是开始，接下来该才是本文的重点：备用机的养成。

关闭系统更新

就像 Windows 会在不经意间自动更新你的电脑，手机也会悄悄地自动更新系统。并且无论是全新设备还是二手机器，系统更新带来的不一定都是正向优化，尤其是跨 Android 版本的系统更新。因此，新到手的设备要做的第一步，便是关闭系统自动更新。

除了关闭自动更新，还可以在开发者选项里彻底关闭【系统自动更新】的后台服务，以绝后患。

当然，已经退出系统维护名单的设备不存在这方面的烦恼。

卸载无用程序

不像 iPhone 预装的都是果子自家的 APP，安卓设备都会预装一些不管你用不用得上的第三方 APP。这些 APP 如果从来没打开过还好，一旦启动，即便只是失手点开从未浏览过任何内容，它也会孜孜不倦地向你推送通知——大多数都是垃圾消息。

所以这第二步，就是一定及时要卸载手机中不使用的 APP。

例如，各家都可能预装的微信支付宝抖音，如果不使用的话请及时卸载。

锁屏画报也卸载掉，没什么大用还费电。

输入法可能预装了不止一种，可能会同时预装搜狗、百度乃至讯飞。选择你习惯使用的，其余的都卸载掉。

地图也可能预装了不止一个。想来备用机也没有查地图的必要，择一或全部卸载。

若是既无法卸载也不能停用，那么只能可以考虑禁用相关权限了。

关闭系统广告

卸载完 APP 还不够，系统内置的广告和内容推荐才是养成的大头。

系统个性化广告/推荐：在系统设置里搜索「广告」或「推荐」，找到「个性化广告服务」、「用户体验计划」、「智能服务」等选项，全部关闭。

小米支持一键关闭部分系统广告。

ColorOS 只支持关闭跟踪标识，并不支持关闭广告。

天气/日历/下载管理器/手机管家：进入这些 APP 的设置，关闭里面的「内容推广」或「信息流」选项。

ColorOS 需要在各 APP 的「隐私」设置中关闭推荐。

小米的广告开关则在「用户体验计划」或「信息流」中。

负一屏（智能助手）：负一屏也是广告重灾区。如果用得到，就只保留需要的功能；如果不用，可以直接关闭这个功能。

文件夹推荐：部分系统会在桌面文件夹里推荐应用，需要长按文件夹，关闭「今日推荐」。

应用商店：进入手机自带的应用商店或软件中心，在「设置」里关闭所有的「消息推送」和「内容推荐」。

可惜应用商店不能卸载也不能停用，不然卸载了之最为妥当。然后装个酷安。至少酷安不会推送广告。

浏览器：系统自带浏览器也是广告重灾区，一般不可禁用、卸载，但可以考虑禁用通知或联网权限，并用其他第三方浏览器替代。

限制应用权限

如果某些 APP 并不经常使用，那么建议限制这些应用的部分权限。

例如：

自启动：除了关闭自启动，更要管理好「关联启动」，防止「一人得道，全家升天」。
后台活动：进入每个应用的「电池」或「电量」设置，将不常用的 APP 后台活动设置为「禁止」或「严格限制」。
网络权限：对于某些单机应用或你不想让它联网的应用，可以在设置中关闭其使用移动网络和 WLAN 的权限。
通知权限：除了禁用通知，还可以利用系统的「通知分类」功能，只保留最核心的通知。

优化电池续航

关闭非必要连接：关闭蓝牙、NFC、定位服务（GPS）、用户体验计划等。需要时再手动开启。
关闭息屏显示（AOD）：除非有特殊用途，否则建议关闭息屏显示。

进阶

理论上来说，上面这些操作已经足够提升备用机的使用体验了。但假如你愿意再深入调教一番，下面这些小工具能让你的备用机体验更上一层楼。

高级权限

如果你的备用机可以很方便地解锁 BL，那么相应地获取 root 权限也便非常简单。但假如是不能解锁 BL 的机器，则可以考虑通过其他方式获取稍微高级一些的 ADB（Android Debug Bridge）权限，比如使用 Shizuku。

Shizuku 在通过 ADB 获得权限后，允许其他程序通过 Shizuku 便捷地调用系统 API，从而实现更强大的功能。

安装 Shizuku 非常简单，Android 11 及以上版本通过无线调试便可直接启动，无需连接电脑。唯一不足的是由于系统限制，每次手机启动后都需要再次进行启动步骤。

开启开发者模式

打开设置，找到「关于本机」，点击「版本信息」，连续点击「版本号」7 次，开启「开发者选项」。
启用无线调试

找到「开发者选项」，并开启「USB 调试」、「无线调试」。无线调试需要连接到 WLAN 后方可使用。
在无线调试中点击「使用配对码配对设备」。
随后在 Shizuku 中按照步骤配对并启动应用。

就可以使用 Shizuku 了。

冻结应用

安装过 Shizuku 后，就可以方便地使用冰箱的冻结功能。

冰箱可以通过 Shizuku 获取提升权限，从而冻结任意软件，包括系统软件。就比如上面提到的锁屏画报，或是系统浏览器，甚至是系统自带的视频、音乐等等你用不到的不可卸载程序，都可以冻结。

但万万不可冻结应用商店、应用安装器，可能会导致手机无法开机。建议在冻结之前，使用「机型 + 冰箱 + 冻结」等关键词在酷安搜索前人的经验。

短信转发

如果你的备用机插了电话卡，电话卡绑定了某些 APP，那么使用短信转发器可以方便地将验证码自动转发到你的主力机上。

安装短信转发器后，按照操作流程授予读取短信、通知类短信权限，关闭验证码保护，并设置自启动，禁用电池限制。选择一个合适的发送通道（比如 iOS 上推荐使用 bark），再设置好转发规则，测试成功后，就可以彻底将备用机丢进抽屉里了！

你可以参考少数派上《巧用开源方案，零成本实现验证码短信转发》关于短信转发器的详细说明。

最后

到这里，你的备用机应该可以彻底焕发新生，重回第二春了。至于使用 GKD 跳过广告、通知滤盒 收纳无用通知、R-安装组件 替换系统自带安装器、Lspatch 安装内嵌模块的应用等等备用机上可能用不太到的东西，这里就不细说了。诸位有兴趣可以自行搜索尝试。

~~写着写着越发感觉偏离主题，这哪是备用机养成，分明就是主力机的优化指南嘛！再说，都叫备用机了，买回来往抽屉里一丢，也不是不行……~~

嘛，说到底，折腾备用机的乐趣，或许并不在于结果，而在于「养成」本身。毕竟这么一番折腾下来，不觉得很酷吗？~~作为一名理工男我觉得这太酷了，很符合我对未来生活的想象，科技并带着趣味。~~

之前有在酷安看到安装 Terminal APP 使用 Linux 环境的帖子，但是这次搜索的时候，看到《Trying Out the New Android Linux Terminal》这篇提到，Google 已经在 Android 15 上提供了原生的 Linux 开发环境。不过似乎仅限 Pixel 用户尝鲜。 ↩

2024 下半年新番吐槽

2025-05-20 21:58:00

最近都看了些什么新番呢？在工位上摸鱼的时候，我突然想起了这件事。

翻了翻新番列表，好像已经有很长一阵子没能花上一整个下午的时间，专心致志地观看一部动画了。掰着指头数了数，大概是来这里牛马之后，就不再有过。每天都在上班，下班晚饭过后的一点点时间，都不够用来刷沙雕图、打游戏、熬夜。即便时间（没有什么事情要做）、空间（找到一个舒服的看番姿势）、番剧（确实有现在就想看的番剧）俱备，足够我正儿八经地看一集新番。可下一秒拿起手机，就放不下了。

所以挤出时间来——准确地说是全神贯注地看完一集 24 分钟的动画，是不太可能的。

可是，再不看动画片的话，感觉自己都快要越过那道门槛，转职成为正统的魔法使了。等到了那时，就真的没啥时间看这些「小孩子家家」的东西了。我甚至能想象得出，当我胡子拉碴、呆毛丛生、津津有味地享受一部后宫番的时候，路过的同事 / 长辈 / 路人甲会是什么样的反应。他们可能只是好奇地看了一眼我的屏幕，随即投来惊讶的目光；语气可能不会太过鄙夷，但一定会说出「你竟然还在看动画片？」这句话。我大概率会无所谓地回复「是啊，怎么了？」，然后继续对着屏幕傻笑。也可能会羞愧难当地关掉动画片，转而刷起短视频。

搞不好我还会因此开启无职的异世界生活。

总而言之，为了自己定下的目标 ¹，为了不让这个系列就此终结，多少还是花了些时间看番。可随之而来的是另一个问题：这下半年能看的新番，似乎有点太少了。

比如作画炸裂的《擅长逃跑的殿下》，剧情和风格上没能支撑我继续追下去，看了一集便搁置了，即便它是由创造出《更衣人偶坠入爱河》和《孤独摇滚！》的梅原 P 企划的。再如讨论度极高的《不时轻声地以俄语遮羞的邻座艾莉同学》，若不是一开始有腹黑的妹妹，我也不可能看得下去六集。后期不仅妹妹变得没意思了，剧情还离谱得让人大跌眼镜，简直是在摧残我所剩无几的智商，幸亏忙得没时间看及时止损。最让人惋惜的是《小市民系列》，本该最让人有所期待的剧情，做着做着就只剩下 2.39:1 的画面还称得上是「电影感」。至于《【我推的孩子】第二季》，我想找个空闲的时间一口气看完，《物语系列外传季&怪物季》则是前几部没补完没法续上剧情看不成。因此，7 月番就只看完了《败犬女主太多了！》、《义妹生活》以及《魔法少女与邪恶曾经敌对。》。

我遂将希望寄托在 10 月，可亦是一言难尽。疯房子不知道发什么疯，在《地。 ―关于地球的运动―》里大搞闪光弹偷袭，还算优秀的原作遇上脑子有洞的改编也是倒霉；《青之箱》只有霸权社制作的动画 OP 以及前 6 集还有点看头，一到真枪实弹的运动场景，作画便崩坏得难以下咽。更何况大多分镜几乎照搬漫画，算不上是优秀的改编。最终，也只看完了《胆大党》和《悲喜渔生》。如果把《英雄联盟：双城之战第二季》也算上的话，倒是和 7 月持平。但《双城之战2》除了画面，剧情深度比第一季要浅得多，远不如第一季好看。

那就不难下结论了：7 月有话题度的原创太少，10 月续作太多，能看的异世界又趋于零，下半年除去续作，就是没啥好看的新番。

两个季度的量加起来还不及 4 月看过的新番的一半，我只能把 2013 年的《冰菓》，2017 年的《游戏人生零》，2021 年的《剃须。然后捡到女高中生。》和《漂流少年》翻出来补上一补。

错的不是我，是这个世界。

~~没有素材，我怎么可能写得出追番报告？所以，我把这些碎碎念搬了上来，加起来足足有一千个字！（啊不是）~~

咳咳，言归正传，让我们开始这一期的新番吐槽吧！

败犬女主太多了！

「败犬」一词，通常用于多女主角的恋爱喜剧中，指代那些未能赢得男主角青睐、却又故作坚强的女性角色。这类角色往往在主角感情确立后逐渐退居二线，直至成为成长回忆的一部分。但从角色塑造来看，「败犬们」大多具备较鲜明的人物特征，情感爆发也比女主角更激烈、更显戏剧化，只是受限于既定的结局走向而被迫退场——正因如此，不少作品中的败犬角色比女主角更受观众喜爱。~~我永远喜欢泽村·斯潘塞·英梨梨。~~

《败犬女主太多了！》的革新，恰恰就在于颠覆了这一传统。它不再执着于讲述「成功人士」的青春，而是将「败犬」置于舞台中央，将叙事权交还给这些「落败者」。由此，我们才得以看到这些性格各异却又充满感染力的角色，以及失败的她们所展现出来的青春：运动系的烧盐柠檬表现出青春期特有的微妙距离感，内向文学少女小鞠知花则细腻地展现了憧憬与现实错位后的自我修复过程。至于外向活泼的八奈见杏菜，她的恋情虽然略显「草率」，却也在分享喜好与情感的过程中，展现了青春期直率而热烈的一面。

本作另一巧妙之处，在于男主角温水和彦这一「背景系」角色的独特视角。某种意义上，他的存在使本作更接近群像剧的结构，而非标准的恋爱胜负游戏。

温水几乎不主动处理角色间的矛盾纠纷，却又不会拒绝参与这些事端。这种若即若离的态度使他与角色们保持了一定距离，却也因此达成了「理想的倾诉对象」的必要条件。他不仅为每位女主留下足够的表达空间，更让她们得以按照自己的节奏修复情感创伤。即便他声称自己不会被青春期阴晴不定的恋爱关系扰乱内心，却仍无可救药地成为了「恋爱」的局中人。

可以说，《败犬女主太多了！》并没有真正突破青春恋爱番的叙事边界，但它尝试以「败犬」作为引子，呈现出更多元的青春视角。在胜者逻辑横行、异世界题材层出不穷的当下，这种平静却充满自省的校园叙事，反而为青春题材注入了难得的真实与珍贵。

义妹生活

但凡看过一些稍微正常的动画，都会在第一眼见到《义妹生活》的时候就把它划分到「便宜动画」的阵营——色彩、场景乃至分镜都透露着一股穷酸味，你很难在这部动画中见到一丁点显经费的地方。就连本作唯一显眼的画风精美的人设，绝大多数时候都是用远机位拍摄人物全身，几乎不存在细节特写。看看隔壁《艾莉同学》，几乎是把能展示角色魅力的招数全都使了出来。

可就是这样一部动画，在这等有限的制作资源的前提下，通过大量值得推敲的演出、细腻而富有深意的叙事结构，展现出与作画严重不符的高水平制作。

空旷的房间和昏暗的光线，是从环境上侧写角色的心理；频繁出现的远景以及奇怪的机位，除了省钱外，也能很好地展示角色的内心活动；就连多到数不清的长镜头，也是用以突出角色的沉默。这直接使得本作的画面虽然廉价，却在整体视觉反馈上表现出非凡的「电影感」。

除了摄影，本作的音乐和配音方面也同样表现出色，配音演员的表现亦为角色增添了层次感。可以说正是因为演出和音乐的互相配合，才得以让贫瘠的画面表现没那么惹眼，使得观众更能沉浸到故事中去。

不知道是什么原因，动画 OST 迟迟没有公布，极有可能会和第二季一样成为有生之年。不过在 B站找到了 BD 附带的三首 OST：https://www.bilibili.com/video/BV1EKcteqEGX

不过很遗憾，我仍旧不擅长从制作、摄影等更深层次的角度对作品做阅读理解，因此只能写到这里了。如果你也对这部动画感兴趣的话，可以在看过动画之后，浏览下面这些文章或视频，加深对动画的理解。

bangumi 番组计划：

哔哩哔哩：

至于要不要因此去看原作小说，这个就没法建议了。毕竟日轻和动画是两种载体，本作原作小说的评分到后期也在逐渐走低……

魔法少女与邪恶曾经敌对。

《魔法少女与邪恶曾经敌对。》其实算不上多么优秀的作品，但其本身承载的重量，使得这部由十年前的漫画而改编的番剧变得「不那么一般」。

作为藤原可可亚的遗作，漫画连载至第 20 话时，因作者病逝而戛然而止。彼时，米拉与白夜之间的关系刚从「敌人」悄然转向「朋友」，魔法少女与邪恶组织的背景也才揭开冰山的一角。邪恶组织的成员看似荒诞却各有伏笔，魔法少女阵营也开始露出不那么光鲜的另一面。这些设定和角色还远未被充分展开，便因为作者的离世永远停在了起点上。

这像是一个永远说不完的故事，你隐约知道后面可能会发生些什么，却再也看不到、也听不到那一句真正从角色口中说出的「我喜欢你」。

这份遗憾，就像片头曲的歌词所写的那样，「保持尚未完结就好，这份情感无需谢幕」。也许作品的动画化，就是对作者最好的追思吧。

胆大党

《胆大党》是少年 Jump 王道漫画的一大代表，因此依旧逃脱不了这类漫画的基本要素：「友情」、「热血」和「胜利」。但是，本作由汤浅政明创立的サイエンスSARU 制作，尽管其本人已退休，但他的个人风格明显已经成为该工作室的视觉语言之一。原作中外星人与超能力的设定，经由那种夸张变形的动作表现与强烈的节奏感，两者的融合带来了远超原作的视听张力，使这部作品在延续王道精神的同时，也展现出动画作为独立媒介的表现优势。

即便你对这类传统 Jump 套路已感疲乏，本作依然可以凭借其独特的演出风格与节奏控制，重新唤起你对这类作品的观看兴趣。

悲喜渔生

在《悲喜渔生》中你可以看到：

让你恨得咬牙切齿的低能男主角
一群热心肠钓鱼佬²
空军
六十年历史背书

《悲喜渔生》带给了我太多出乎意料的惊喜，即便它的 OP 带电，即便男主的性格惹人生厌，即便它的故事并不惊艳，它仍旧是这个10月最值得一看的原创番剧。

从钓具的挑选、下窝的策略，到抛线的时机、收杆的节奏，与钓鱼相关的每一个细节都被刻画得细腻真实。而配乐更是《悲喜渔生》的灵魂——伴随着抑扬顿挫的旋律，钓鱼的节奏与情绪被巧妙烘托，即使是从未垂钓过的人，也能凭借音乐感受到那种或舒缓、或紧张、或充满期待的情绪波动，进而不知不觉沉浸于故事之中。以至于身为观众的我，也有想要放下一切负担，独自一人乘着海风随心所欲地钓上一杆的冲动。

但钓鱼之外，是作品对「钓鱼即是人生」这一主旨的始终贯彻。在《悲喜渔生》中，钓鱼不仅是角色们的共同爱好，更是一种生活方式。男主常宏原本对钓鱼毫无兴趣，甚至感到厌烦，但在与便利店同伴们的相处中，他逐渐体会到钓鱼的魅力。钓鱼需要耐心、技巧和对自然的理解，这与他之前急于求成、追求快速成功的人生态度形成鲜明对比。钓鱼的过程充满了不确定性，正如人生的旅程。有时辛苦一整天也未必能有所收获，但每一次出钓都是一次新的尝试和希望。通过钓鱼，常宏学会了放慢脚步，享受过程，重新审视自己的生活方式，在自己做出转变的同时，也解开了贵明积压已久的心病。这种对过程的重视和对结果的淡然，大概就是《悲喜渔生》想要传达的人生态度吧。

在写第一篇新番吐槽的时候，曾暗自定下「每季度完结后写一篇吐槽练练文笔」的小目标。 ↩
喜欢钓鱼的都不会是坏人 ↩

一加 Ace5 Pro 快速上手及刷机小记

2025-05-08 22:29:00

随着小米逐渐收紧手机 Bootloader 解锁政策，一加手机便成为了可能是国内最适合刷机爱好者的安卓设备：解锁不设限、Root 后在一定范围内支持保修。我能理解厂商封堵刷机的考量，如今的安卓生态早已告别那个功能匮乏、需要靠刷机来弥补的时代，再加上深度定制的 UI 系统和基于硬件的定制化功能，都让第三方 ROM 的生存空间日益萎缩。当刷机变得不再必要，刷机文化式微是必然的趋势。但安卓的魅力，始终来源于它的开放性，我还清楚地记得在小米 5 上实现三系统共存时那种纯粹的快乐——即便这并没有什么意义。

在因骁龙 888 的拉胯而从小米 11 转向 iPhone 之后，我已经有 4 年没接触过刷机了。这次有幸拿到一部一加 Ace5 Pro，机主( おとうと) 拜托我帮忙解锁并隐藏 Root，我得以借此再过一把刷机的瘾。

本文是机器快速上手及刷机过程的简要记录。

关于手机

一加 Ace5 Pro 发布于 2024 年 12 月 26 日，搭载当下最新的旗舰芯片高通骁龙 8 至尊版( Snapdragon 8 Elite)，配备 6.78 英寸的直面屏和 6100mAh 大电池，整机仅重 203g，和我手上的 iPhone 比较，轻得相当明显。

既然定位电竞手机，这样的配置倒还算中规中矩。我手上这台是 12GB+256GB 的内存和存储，只是打游戏的话还算够用，即便再安装个微信也不在话下。~~但要拿微信办公的话得另当别论。~~

后置三摄采用浴霸式排布，最高像素 5000 万。随手在昏暗的室内拍了一张，感觉色彩比我的 iPhone 要鲜艳一些。

拍照水平太次，看不出所以然来。

不过话说回来，可能是我太久没关注安卓市场，再加上之前基本只接触过小米的缘故，对其他品牌的产品线了解相当有限。我只能顺着「小米数字系列是高端旗舰，Redmi K 系列是中高端旗舰」的逻辑，猜想只划分为数字和 Ace 两条产品线、价格区间也近似的一加，定位应该也差不多。可是查询参数时才惊讶地发现，搭载相同 CPU 的一加 Ace5 Pro 居然比一加 13 的安兔兔跑分高了三万多。只能归结于晚发布的 Ace5 Pro 在芯片调教上要比老前辈更成熟一些。

关于系统

现在的一加预装的是和母公司 OPPO 一样的 ColorOS，我这台一加 Ace5 Pro 搭载的是最新的 ColorOS 15。这是我第一次使用 ColorOS，新鲜感虽谈不上十足，但也有些好奇心在。

桌面中规中矩，看不出明显的差异，至少和我印象中的氢 OS 不太相似，毕竟氢壁纸在当时可算是独一档的设计。~~（我这是什么老古董）~~

毕竟现在的系统大都趋于雷同，做得太复杂是需要额外的上手成本的。

所以我直奔系统预装应用，倒要看看是不是只有小米才会预装一堆垃圾。

果不其然，大家都是半斤八两。

可当我尝试批量卸载这些应用时，才注意到无法直接在 抽屉模式 下批量卸载它们，提示仅能移除图标。

小米不是这样教我的诶，我记得把这些图标往顶栏拖动，是有一个按钮可以直接卸载的。

翻了翻桌面设置，才注意到 ColorOS 的桌面只有在 标准模式 下，才能批量卸载应用。

抽屉模式下，需要进入应用抽屉，点击右上角「管理」，勾选应用后，才可以批量卸载。

奇怪的逻辑。

预装应用如此，广告尤甚。ColorOS 锁屏默认使用「乐划锁屏」推送垃圾新闻、短视频和广告不说，系统自带应用还有无法关闭的广告。尤其是自带浏览器。浏览器不仅有开屏广告，主页还充满了各种各样低俗的广告。网页无法打开时还会推送低俗新闻，锁屏后重新打开浏览器还会弹一次开屏广告。即便能切换成极简模式，搜索框中也无时无刻不在滚动着广告推送。

乐划锁屏倒是能关，可这浏览器怎么都找不到关闭广告的入口。小米被骂了一顿之后老实了不少，系统广告大部分支持关闭。但一加我简单翻了翻，没有看到明显的关闭广告的选项。顶多一刀切关闭通知，或者卸载了之。

不过在试着整理桌面时，意外地发现 ColorOS 的应用文件夹居然支持自由调整大小。不仅可以横向/竖向拉伸，还能变成长条形、方形等不同布局。~~如果 iOS 能把这文件夹调整方式抄了去的话，我的桌面也能变得好看一些。~~

对比小米的设计，ColorOS 的处理方法明显更灵活，实际使用起来也顺手得多。

还发现了一个叫做「一加互传」的功能，写着支持 iPhone。我以为会是使用相同协议无感传输的那种，结果还是需要在 iPhone 端安装「O+互联」APP 才能互相传输文件。那和两台设备都安装一个互传应用并没有什么实质上的区别，只是一加自带了这个互传 APP 而已。

还有其他基于机载 AI 的功能，因为需要登录欢太账户，没能体验；另外骁龙 8 至尊版的游戏性能，因为只是解锁刷机，也没有深度测试一番。

~~最后是把小米 11 刷成 ColorOS 体验了番 AI……~~

关于刷机

一加解锁 Bootloader 不像小米需要下载专用的解锁工具，直接在「开发者选项」中允许「OEM 解锁」，再重启至 Fastboot 模式，然后使用 fastboot 命令，即可完成解锁，非常简单。

至于获取 Root 权限，我还停留在使用 Magisk 获取 Root 的古早思维，不知道现在是不是有什么新的方式。网上搜索了一圈，都推荐使用 KernelSU 获取 Root 权限。简单翻阅了下官方文档，似乎使用 LKM 模式 修补官方 init_boot.img 镜像的方式，和为 Magisk 修补 boot.img 镜像差不多。按部就班实操了一遍，成功获取到了 Root 权限。

刷机有风险，请做好救砖的心理准备！！！

准备

在开始之前，需要准备以下工具：

ADB Tool：用以执行 adb 和 fastboot 指令，传送门
Fastboot 驱动：解决 fastboot 指令不生效的问题，传送门
payload-dumper-go：提取原厂系统安装包中的 init_boot.img，用以后续修补 KernelSU，传送门
KernelSU 管理器：管理 Root 权限，传送门

解锁

首先，打开设置，下拉至「关于本机」，点击「版本信息」。接着连续点击顶部「版本号」7 次，开启「开发者选项」。

返回设置。下拉至「系统与更新」，点击「开发者选项」，找到「OEM 解锁」并开启，以允许解锁引导加载程序；开启「USB 调试」，以便后续连接电脑执行解锁命令。

将手机通过 原装数据线 与电脑相连接。接着，打开我的刷机传家宝 ADB Tool，双击 打开CMD命令行.bat ，弹出终端窗口后输入：

adb devices

此时手机应当会弹出 USB 调试 授权，勾选 一律允许 并确认即可。

终端中会输出 List of devices attached 列出当前 adb 设备。

随后，再执行：

adb reboot bootloader

等待手机重启至 Bootloader 模式。

一加的 Bootloader 模式，屏幕左上角有一个显眼的 START 提示，下方以英文标注：

Press volume key to select, and press power key to select.

意为「使用音量按键选择，按下电源按键确认选择」。

以红字 DEVICE STATE - locked 提示设备已上锁。

完整示例如下，仅供参考：

-----------------------------------
START
-----------------------------------

Press volume key to select, and press power key to select.

FastBoot Mode
PRODUCE_NAME - sun
VARIANT - SMB UFS
BOOTLOADER VERSION -
BASEBAND VERSION -
SERIAL NUMBER - abcedf
SECURE BOOT - yes
DEVICE STATE - locked

在 adb 工具中输入：

fastboot devices

如果正常如下图输出设备代号，即可继续执行解锁命令。

如果没有任何输出，请安装驱动，或是检查线材、数据线与手机 PC 的连接状态。

总之，在 fastboot devices 命令有正常输出后，继续在终端中输入解锁命令：

fastboot flashing unlock

此时终端中应当会提示：

D:\ADB Tool>fastboot flashing unlock
OKAY [  0.015s]
Finished. Total time: 0.016s

而手机上会出现解锁相关的警告。按 音量下键 选中 UNLOCK THE BOOTLOADER，再按下 电源键 确认解锁。

解锁将自动清空所有数据，并自动重启至开机引导模式。

修补

根据 KernelSU 官方文档的说明，需要先检查设备是否支持使用 KernelSU。下载并安装 KernelSU 管理器后，打开 KernelSU。

如果应用程序显示 “不支持”，则表示您的设备不支持 KernelSU，你需要自己编译设备的内核才能使用，KernelSU 官方不会也永远不会为你提供一个可以刷写的 boot 镜像。

如果应用程序显示 “未安装”，那么 KernelSU 支持您的设备；可以进行下一步操作。

咱的设备当然是支持的，估计是一些不常见的古董才会不被 KernelSU 支持。

接着，下载官方原版系统更新包。因为不知道从哪里可以获取到完整包，这里使用的是大侠阿木提供的全量更新包度盘链接。

这里我使用的是 PKR110_15.0.0.800(CN01) 版本，度盘中还提供了数个官方下载链接，如果没有度盘会员可以直接使用官方链接下载。

官方链接、官方链接、官方链接、官方链接、官方链接

官方链接、官方链接、官方链接、官方链接、官方链接

接着，解压安装包，获取 payload.bin 文件。

随后，下载 payload-dumper-go，并解压 payload-dumper-go_x.x.x_windows_amd64.zip，打开该文件夹，将上面获取到的 payload.bin 文件移动至该文件夹中。

接着在 该文件夹 空白处右键，选择「在终端中打开」。直接使用以下命令，可以省去将该应用添加到环境变量的步骤：

.\payload-dumper-go.exe payload.bin

由于一般只用得到 boot.img 和 init_boot.img ，可以不必等待全部跑完流程，看到这俩文件被提取出来就可以按 CTRL+C 取消进程，关闭窗口。

本来准备试试一加全能工具箱，但打开就提示「终端设置异常」，即便恢复为「Windows 控制台主机」也无济于事。想了想也就敲几个命令的事，就没再继续修复环境异常，可能是 Win11 下这个工具水土不服吧。

将 init_boot.img 拷贝至手机中，打开 KernelSU 管理器，点击顶部左边第一个按钮，选择修补本地 init_boot.img 。

KernelSU 会将修补过的镜像文件保存在原镜像同路径，命名格式为 kernelsu_patched_xx.img，拷贝至电脑备用。

我这台机子目前的系统版本号为 PKR110_15.0.0.800(CN01)，如果你的版本号和我一致，可以直接使用我修补好的镜像。传送门

但仍注意备份数据，并做好随时救砖的思想工作！！！！

Root

解锁完机子，修补好镜像，Root 就很简单了。先开启「USB 调试」并使用 ADB Tool 确认连接正常后，重启至 fastboot 模式：

adb reboot bootloader

测试 fastboot 连接，确保有正常输出：

fastboot devices

最后，将修补过的 kernelsu_patched_xx.img 使用以下命令刷入系统。

fastboot flash init_boot kernelsu_patched_xx.img

你可以参考下图将文件拖动至工具中，不用手敲文件路径。

提示刷入完成后，再使用 fastboot reboot 命令重启系统。

即可在 KernelSU 中查看到 Root 状态。

隐藏

~~本来是计划把隐藏的方法完整记录下来的，奈何老弟整活把手机搞到无限重启，只能双清恢复出厂设置。我没有及时保存截图，一切努力付诸东流……~~

关于 KernelSU 的用法以及隐藏 Root 的方法，这里就不赘述了。可以尝试使用 KernelSU 自带的功能对特定应用还原环境，或是在安装 ZygiskNext 模块后，使用 LSPosed 框架配合隐藏应用列表隐藏特定应用。如果仍被检测到 Root，或是提示对系统已被改动，可以尝试安装 PlayIntegrityFix 和 TrickyStore 模块，一般就能摆脱嫌疑。

回锁

~~老弟发现这机子内核版本太高，不适合他搞小动作，准备退货。所以我辛辛苦苦解锁完、折腾完 Root 隐藏，还得全部清空给它锁回去……~~

上锁的话，需要先在 KernelSU 中选择「永久卸载」移除 Root 权限和所有模块，还原原厂镜像。

保险起见，再使用完整包更新一遍系统，确保所有文件都恢复为原厂文件。

然后按照解锁的方式进入 fastboot 模式，使用以下命令回锁：

fastboot flashing lock

手机上会弹出提示，选择锁定菜单即可。

重启手机后，如果开机界面没有出现设备已解锁的提示，就说明回锁成功了。

但看说这个操作非常危险，有概率使设备变砖，我只是运气好才一次成功。大家千万不要没事干解锁回锁反复横跳……

关于救机

如果因为瞎折腾导致无限重启什么的，可以尝试使用电源键+音量减键进入 Recovery 模式，尝试清除系统数据，看看能不能再次回到开机引导界面……

文章参考

文中提到的所有应用和工具：

解锁和 Root 方面的参考：

mikusa | 初之音修改