不想睡觉，万无目的的刷着视频，就只是不想面对明天的生活。

前言#

如果你在云计算、DevOps 或后端开发的世界里混过，一定听过 “Docker” 和 “Kubernetes”（简称 K8s）这两个词。很多人认为它们是同一回事，或者搞不清楚它们之间的关系。实际上，它们是两个不同的工具，但关系紧密。本文将从零开始，帮你理清这两个概念。

Docker 是什么？#

核心概念#

Docker 是一个容器化平台。它允许你将应用程序及其所有依赖（代码、运行时、库、配置文件等）打包成一个标准化的单元，称为 容器。

想象一下：

• 传统方式：你需要在服务器上安装 Python 3.9、Node.js 14、MySQL 5.7 等各种依赖，然后才能运行应用。不同的开发者电脑可能配置不同，导致”在我电脑上能跑”的尴尬局面。
• Docker 方式：你把应用和所有依赖打包成一个镜像，无论在开发者的 Mac、Linux 服务器还是云平台上，都能以完全相同的方式运行。

Docker 的两个核心概念#

1. 镜像（Image）

   • 一个只读的模板，包含应用程序和所有依赖
   • 类比：电脑的系统安装盘或快照
   • 通过 Dockerfile 定义如何构建镜像

2. 容器（Container）

   • 镜像的运行实例
   • 类比：从快照启动的一台虚拟机
   • 轻量级、隔离、快速启动

Docker 的价值#

1
2
3
4
5
6

# 一个简单的 Dockerfile 示例
FROM python:3.9
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

用一个 Dockerfile 定义环境，任何有 Docker 的地方都能运行这个应用。这解决了开发环境和生产环境不一致的问题。

Kubernetes 是什么？#

核心概念#

Kubernetes 是一个容器编排平台。它的工作是管理和运行大量的容器。

想象一下：

• 你有 100 个 Docker 容器需要在 10 台机器上运行
• 其中某个容器崩溃了，需要自动重启
• 需要根据流量自动增加或减少容器数量
• 需要在容器间进行网络通信和负载均衡
• 需要管理存储、配置、秘密数据等

如果手动处理这些事情，会疯掉。Kubernetes 就是为了解决这个问题而诞生的。

Kubernetes 的核心特性#

1. 自动化部署和扩展

   • 自动决定容器在哪台机器上运行
   • 根据 CPU/内存使用率自动扩容/缩容

2. 自我修复（Self-healing）

   • 容器挂掉了自动重启
   • 定期健康检查

3. 负载均衡和服务发现

   • 自动负载均衡流量
   • 容器间可以互相发现和通信

4. 资源管理

   • 限制每个容器的 CPU 和内存
   • 高效利用集群资源

5. 滚动更新

   • 可以无停机更新应用
   • 版本回滚

Docker 和 Kubernetes 的关系#

一句话总结#

Docker 是打包应用的工具，Kubernetes 是运行和管理这些打包好的应用的平台。

更详细的解释#

1
2

开发流程：
代码 → Docker → 镜像 → 容器 → Kubernetes 管理这些容器

1. 包含关系，不是替代关系#

• Docker 负责 “怎样打包”
• Kubernetes 负责 “怎样运行和管理”
• 没有 Docker，你仍然可以使用其他容器（如 Podman、containerd）
• 没有 Kubernetes，你仍然可以手动运行 Docker 容器（但会很痛苦）

2. 具体例子#

假设你有一个 Web 应用：

第一步：用 Docker 打包

1
2
3
4
5
6
7

FROM node:14
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "app.js"]

构建镜像：docker build -t myapp:1.0 .

第二步：用 Kubernetes 管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3  # 运行 3 个容器实例
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:1.0  # 使用 Docker 镜像
        ports:
        - containerPort: 3000
        resources:
          limits:
            memory: "256Mi"
            cpu: "250m"

Kubernetes 会：

• 根据这个配置创建 3 个容器
• 在集群的不同节点上分布它们
• 如果其中一个容器崩溃，自动重启
• 如果需要更新，逐个替换容器（滚动更新）

Docker 和 Kubernetes 的对比#

什么时候用 Docker？什么时候用 Kubernetes？#

用 Docker 的场景#

• 本地开发测试
• 简单应用部署（1-2 台服务器）
• CI/CD 流程中的打包步骤
• 学习容器化基础

用 Kubernetes 的场景#

• 生产环境微服务架构
• 需要自动扩缩容
• 需要高可用性
• 多个服务需要协调
• 团队规模较大

常见误解#

误解 1：Docker 和 Kubernetes 必须一起用#

真相：Kubernetes 可以使用其他容器运行时（如 containerd、CRI-O）。Docker 也可以独立使用。但在实际中，它们的组合非常流行。

误解 2：学会了 Docker 就能用 Kubernetes#

真相：Docker 是基础，但 Kubernetes 是一个全新的概念。需要学习 Pod、Service、Deployment、ConfigMap 等 K8s 特有的概念。

误解 3：Kubernetes 可以完全替代 Docker#

真相：不能。Kubernetes 需要容器技术作为基础。它只是在容器之上添加了编排层。

快速开始体验#

本地尝试 Docker#

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 创建一个简单应用
echo 'print("Hello from Docker!")' > app.py

# 创建 Dockerfile
cat > Dockerfile << EOF
FROM python:3.9
COPY app.py /app/
WORKDIR /app
CMD ["python", "app.py"]
EOF

# 构建和运行
docker build -t hello-app .
docker run hello-app

本地尝试 Kubernetes#

1
2
3
4
5

# 安装 minikube 或 Docker Desktop with Kubernetes
# 然后创建上面提到的 deployment.yaml 文件
kubectl apply -f deployment.yaml
kubectl get pods
kubectl logs <pod-name>

总结#

• Docker 解决的是 “怎样打包应用” 的问题
• Kubernetes 解决的是 “怎样运行和管理大量容器” 的问题
• 它们是互补的关系，而不是竞争或替代关系
• 了解 Docker 是学习 Kubernetes 的前提
• 在生产环境，它们通常是”黄金搭档”

希望通过这篇文章，你能更清楚地理解这两个工具的关系。如果你有具体的应用场景需要帮助，欢迎继续提问！

推荐学习路径#

1. 第一步：深入学习 Docker 的基础概念和常用命令
2. 第二步：用 Docker 打包自己的应用
3. 第三步：在本地用 Minikube 体验 Kubernetes
4. 第四步：学习 Kubernetes 的核心资源对象（Pod、Service、Deployment）
5. 第五步：在真实集群中实践

祝学习愉快！🚀

在维护 Linux 服务器时，我们经常会看到“系统负载（Load Average）”这个指标。它是衡量系统忙碌程度的核心数据。

1. 如何查看系统负载？#

Linux 提供了多种工具来查看负载情况，最常用的包括：

uptime 命令#

这是最简单直接的方法：

1
2

uptime
# 输出示例： 15:20:01 up 10 days,  2:10,  1 user,  load average: 0.52, 0.40, 0.35

top 或 htop 命令#

top 是系统内置的实时监控工具，而 htop（通常需要额外安装）提供了更直观的彩色界面。

• 在 top 的第一行可以看到 load average。
• 在 htop 的顶部栏也会显示相同的信息。

cat /proc/loadavg#

如果你想通过脚本获取原始数据：

1
2

cat /proc/loadavg
# 输出：0.52 0.40 0.35 1/485 12345

2. 负载数值（1.xxxx, 0.xxxx）是什么意思？#

当你看到 load average: 0.52, 0.40, 0.35 时，这三个数字分别代表：

• 第一个数字 (0.52) ：最近 1 分钟 的平均负载。
• 第二个数字 (0.40) ：最近 5 分钟 的平均负载。
• 第三个数字 (0.35) ：最近 15 分钟 的平均负载。

数值的本质#

在 Linux 中，系统负载是指 处于可运行状态（Running/Runnable）和不可中断等待状态（Uninterruptible Sleep，通常是 IO 等待）的进程平均数 。

我们可以用“大桥交通流”来做类比：

• 负载 = 0.50 ：大桥上的车只占了一半车道，交通非常顺畅。
• 负载 = 1.00 ：大桥上的车刚好占满所有车道，虽然没有堵塞，但已经满载。
• 负载 = 1.70 ：大桥已经挤满了车，还有 70% 的车在桥头排队等待。

3. 负载多少算高？（取决于 CPU 核心数）#

0.xxxx 或 1.xxxx 本身并没有绝对的好坏，它取决于你的 CPU 核心数量。
如果你的服务器有 4 个 CPU 核心：

• 负载为 1.00 意味着系统只使用了 25% 的处理能力（1/4）。
• 负载为 4.00 意味着系统刚好满负荷。
• 负载为 8.00 意味着系统超负荷 100%（有一半的进程在排队）。

计算公式#

我们可以得出每个核心的平均负载指标：
$$\text{Load Per Core} = \frac{\text{System Load}}{\text{CPU Cores}}$$

经验阈值#

通常建议参考 15 分钟 的平均负载：

4. 如何查看 CPU 核心数？#

要准确判断负载是否过高，你需要先知道自己有多少个逻辑 CPU：

1

grep -c 'model name' /proc/cpuinfo

或者使用：

1

nproc

5. 总结#

• 看趋势 ：如果 1 分钟的负载远高于 15 分钟，说明负载正在上升；反之则在下降。
• 看核心 ：永远结合 CPU 核心数来评估负载值。
• 找原因 ：负载高不一定是 CPU 计算压力大，也可能是 磁盘 I/O 阻塞 （大量进程处于等待状态）。

通过定期监控这些数值，你可以及时发现系统瓶颈，确保业务的稳定性。

在互联网世界的浩瀚代码海洋中，我们最常遇到的是 200 OK、404 Not Found，或者偶尔让人心惊的 500 Internal Server Error。但今天，我们要聊的这位“老朋友”，它虽然不常见，但却充满了幽默感和历史气息——HTTP 418 I’m a teapot (我是一个茶壶)。

是的，你没听错，一个状态码居然声称自己是一个茶壶。这听起来像是一个段子，但它却是货真价实的互联网协议草案中的一员！

历史的“煮沸”：HTTP 418 诞生记
一切要追溯到 1998 年，那一年，互联网正在飞速发展，但总有一些工程师觉得，生活不应该只有严谨的逻辑和二进制代码。

当时，互联网工程任务组（IETF）正在起草一个关于超文本咖啡壶控制协议（Hyper Text Coffee Pot Control Protocol, HTCPCP）的草案。这个协议的初衷是用来控制和操作咖啡机。

想象一下，如果你用浏览器向一台智能咖啡机发送请求，你希望它做的是“煮咖啡”，而不是普通的 GET 请求。HTCPCP 就是干这个的。

在这个充满了咖啡香气的草案中，那些富有创造力的工程师们决定加入一个“彩蛋”——如果有人试图用一个茶壶来请求咖啡（或者说，向一个被定义为咖啡机的设备发送不兼容的请求），那么设备就应该礼貌而明确地拒绝，并给出一个最贴切的回复：

“抱歉，我是一个茶壶，我不能冲咖啡。”

于是，HTTP 418 I’m a teapot 就此诞生了。它是一个玩笑，一个对技术规范的善意嘲讽，被戏称为“一个需要被实现的恶作剧”。

为何它“活”了下来？
按理说，一个恶搞的状态码应该很快被遗忘。但 418 却在互联网上拥有了一批忠实的拥护者。

虽然 HTCPCP 协议从未成为主流，但 418 却因为其独特的幽默感被保留了下来，并成为了一个“互联网文化符号”。每当有程序员觉得某个请求荒谬可笑、或者服务器懒得处理时，他们就会开玩笑地回复 418。

它代表着： 互联网的幽默感和对过度规范化的反叛精神。

谷歌的“茶歇时间”：一个可以倒茶的页面
为了致敬这个充满个性的状态码，全球互联网巨头 Google 也加入了这场茶话会。

如果你在电脑浏览器上访问： 👉 https://www.google.com/teapot

你会看到一个非常简洁的页面，上面显示着：

418. That’s what she said.

I’m a teapot.

页面设计得非常简洁，背景是一张可爱的、正在冒着热气的茶壶图片。

📱 手机党的“隐藏惊喜”！
最有趣的是，如果你用手机（移动端浏览器） 访问这个 Google Teapot 页面，你会发现一个“彩蛋”！

试试看： 打开你的手机浏览器，输入 https://www.google.com/teapot。

页面会显示一个动态效果：一个虚拟的茶壶图标会开始倾斜，并“倒出”一串串的数字和字母！

是的，你成功“倒”出了一壶代码茶！这正是谷歌向 418 状态码致敬的互动方式——用可触摸的、动起来的元素来诠释一个纯文本的状态码。

结语
下次当你遇到一个奇怪的 HTTP 错误时，不妨冷静下来，想想那个在深层协议中默默等待的茶壶。它提醒我们，即使是最严谨的技术世界，也需要一点点幽默感和对历史的尊重。

所以，放下你的咖啡（除非你的设备真的是咖啡机），给自己泡一杯热茶，然后打开 google.com/teapot 看看你的“代码茶”是否已煮好！

最近在 GitHub 上刷到一个特别实用的开源项目——Owl，这是一个完全免费的视频监控平台，用 Go 语言开发的，部署起来超级简单。更厉害的是，它不仅支持各种主流的监控协议，还内置了 AI 智能检测功能。看了一圈，感觉这个项目真的很适合分享给大家。

这个项目是干什么的#

Owl 是一个视频监控管理平台，说白了就是让你能把各种摄像头接入进来，然后在网页上统一管理和观看。不管你的摄像头是什么牌子、什么型号，基本上都能接进来用。

这个项目最大的亮点就是开箱即用。不需要你有多深的技术功底，跟着文档操作，很快就能把整套系统搭起来。而且完全免费开源，代码放在 GitHub 上，想怎么改就怎么改。

项目地址：https://github.com/gowvp/owl
在线演示：http://gowvp.golang.space: 15123（用户名密码都是 admin）

有兴趣的朋友可以先去看看在线演示，直观感受一下效果。

为什么值得关注#

说起视频监控，很多人第一反应就是海康、大华这些品牌的商业方案。但问题是，这些方案要么价格不便宜，要么功能被限制得死死的。想自己折腾一套，又发现开源项目大多是 Java 或 C++ 写的，光是把环境搭起来就要费半天劲。

Owl 这个项目就很好地解决了这些痛点：

部署简单到爆。因为是用 Go 语言开发的，编译出来就是一个独立的可执行文件，没有乱七八糟的依赖。再加上 Docker 镜像，一条命令就能跑起来。

协议支持全面。国标 GB28181 协议支持得特别好（2011、2016、2022 三个版本都支持），还支持 ONVIF、RTSP、RTMP 这些常见协议。也就是说，不管你家里的摄像头是国产的还是进口的，新的还是旧的，基本都能接入。

带 AI 检测功能。集成了 YOLO 物体识别算法，能自动识别画面中的人、车、动物等。比如你想知道有没有陌生人闯入院子，或者想统计每天有多少车经过门口，这个功能就派上用场了。

节省带宽。有个很聪明的设计叫”按需拉流”，就是只有当你打开网页看监控的时候，系统才会从摄像头拉取视频。没人看的时候自动停止，这样能节省大量带宽和流量。

功能清单#

看看这个平台具体都能干什么：

设备接入

• 支持 GB28181 标准设备（摄像头、NVR、平台级联等）
• 支持 ONVIF 协议的网络摄像机
• 支持 RTSP 和 RTMP 流媒体设备
• 可以自动发现局域网内的 ONVIF 设备

视频播放

• 浏览器直接播放，不需要装插件
• 支持 H264 和 H265 视频编码
• 支持 G711A、G711U、AAC 音频编码
• 支持多种播放协议：HTTP-FLV、WebSocket-FLV、HLS、WebRTC、RTSP、RTMP
• 可以跨网络观看（内网摄像头，外网也能看）

智能检测

• YOLO AI 物体识别
• 默认每秒检测 5 帧画面
• 可以根据需要关闭或调整检测频率

其他功能

• 设备目录查询
• 设备信息查询
• 实时快照抓取
• 设备校时
• 自动离线检测
• 中文和英文界面切换

手把手教你部署#

好了，重点来了——怎么把这个平台搭起来。作者提供了超级简单的 Docker 部署方案，跟着做就行。

准备工作#

部署之前，你需要确保服务器上已经装好了：

• Docker（必须）
• Docker Compose（必须）

第一步：创建一个目录，比如叫 owl-nvr

1
2

mkdir owl-nvr
cd owl-nvr

第二步：创建 docker-compose.yml 文件

1

nano docker-compose.yml

把下面的内容复制进去：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

services:
  gowvp: 
    image: gospace/gowvp:latest
    restart: unless-stopped
    ports:
      # 管理平台端口
      - 15123:15123
      # GB28181 信令端口
      - 15060:15060
      - 15060:15060/udp
      # 流媒体端口
      - 1935:1935    # RTMP
      - 554:554      # RTSP
      - 8080:80      # HTTP
      - 8443:443     # HTTPS
      - 10000:10000
      - 8000:8000/udp
      - 9000:9000/udp
      # GB28181 收流端口范围
      - 20000-20100:20000-20100
      - 20000-20100: 20000-20100/udp
    volumes:
      # 数据持久化目录
      - ./data:/opt/media/bin/configs

第三步：启动服务

1

docker compose up -d

看到类似 “Container owl-nvr-gowvp-1 Started” 的提示，就说明启动成功了。

第四步：访问管理界面

打开浏览器，访问 http://你的服务器IP:15123

默认账号密码都是：admin

第一次登录建议马上修改密码。

有些地区访问 Docker Hub 可能比较慢，可以改用阿里云镜像：

1

image: registry.cn-shanghai.aliyuncs.com/ixugo/homenvr:latest

AI 检测功能配置#

Owl 默认就开启了 AI 检测，每秒检测 5 帧画面。不需要额外配置，直接就能用。

如果你觉得检测太频繁或者不需要 AI 功能，可以关闭它：

1. 进入容器配置文件：

1

docker exec -it owl-nvr-gowvp-1 cat /opt/media/bin/configs/config.toml

2. 修改配置文件，添加或修改这一行：

1

disabledAI = true

3. 重启服务：

1

docker compose restart

使用 Nginx 反向代理#

如果想通过域名访问，可以配置 Nginx 反向代理。配置文件里加上这几行：

1
2
3
4

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Prefix "https://你的域名";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

适合什么场景#

这个项目特别适合以下场景：

家庭监控：想在家里装几个摄像头看宠物、看孩子，又不想花大价钱买商业方案的。

小微企业：公司规模不大，想搭个监控系统管理办公区、仓库、门店的。

学习研究：想了解视频监控技术、GB28181 协议，或者学习 Go 语言项目开发的。

私有化部署：对数据安全特别在意，不想把视频流传到云端厂商那里的。

老设备利用：手头有一堆旧摄像头，想统一管理起来继续用的。

项目资源#

如果想深入了解这个项目，这些资源可能有帮助：

项目地址：https://github.com/gowvp/owl
在线演示：http://gowvp.golang.space:15123
API 文档：https://apifox.com/apidoc/shared-7b67c918-5f72-4f64-b71d-0593d7427b93

作者还写了一系列开发日记，从零开始讲怎么实现 GB28181 协议，挺适合想学习的朋友：

• GB/T28181 开源日记[1]：从 0 到实现 GB28181 协议的完整实践
• GB/T28181 开源日记[2]：搭建服务端，解决跨域，接口联调
• GB/T28181 开源日记[3]：使用 React 组件构建监控数据面板

等等，一共有 8 篇，都发在掘金上，搜”GB/T28181 开源日记”就能找到。

还有一些使用教程，都挺详细的，新手也能看懂。

写在最后#

Owl 这个项目目前已经有 600 多个 Star 了，社区挺活跃的。作者还在持续更新，下一步计划支持 HomeKit 集成（也就是能在苹果 Home 里看摄像头），还有录像回放、PTZ 云台控制等功能。

如果你正好有视频监控的需求，不妨试试这个项目。部署真的很简单，10 分钟就能跑起来。就算最后没用上，折腾一下学点东西也挺好的。

你有没有遇到这样的烦恼？工作中用到各种图片处理，找了半天好用又免费的图床，非得付费才能用高级功能；或者用的开源项目，界面老旧体验差，还没人维护。说真的，这种需求其实一天比一天多，特别是我们这些喜欢DIY、小白NAS用户，期待能有一款既自由又好用的图床。

最近我发现了一个名字叫“云图”的项目，它特别适合想自己搭个私有图床的人用。说白了，它就是一个适合个人的超级实用的图床服务，你可以把所有图片放里面，随时调用、管理，完全不用担心到处散落或者第三方突然变收费。

云图是什么？#

云图是一个开源的私有图床项目，作者是为了满足自己在自动化工作流（像N8N）的图片处理需求，自己动手写出来的。相比市面上那些龟速更新、功能受限的传统图床，云图开放、灵活、功能丰富，还支持无感缩略图加载，体验特别棒。

你甚至不用担心复杂的部署，它能通过一条简单的docker-compose配置文件一键启动，轻松挂载你NAS上的文件夹，完全符合咱们这种“闲人挂着用”的生活方式。

用起来到底怎么方便？#

• 上传图片简单：支持拖拖拽拽批量上传，甚至能上传Base64编码的图片，适合自动化脚本调用。
• 图片随时变变变：只要URL加上参数，就能改变尺寸、质量和格式，比如上传一张原图，调用时可以自动转成WebP、调节宽高，节省带宽又清晰。
• SVG转PNG，一键搞定：设计师的神助攻，SVG转成通用图片格式，完美兼容各种地方展示。
• 相册分享，直接发链接：过去分享时还得打包，搞得一团乱。用云图，点几下就能生成独立分享链接，对方打开就能看高清图，省得你东奔西跑。
• 回收站功能安心用：怕误删图片？手滑删错了也别慌，图会先进回收站留30天，想恢复很方便，不用紧张。
• 全平台适配，随时随地看图：不管你用手机还是电脑，界面都自适应，还支持深色模式，晚上看也不刺眼。
• 支持其他文件格式上传：不仅限于图片，云图也能用来存放你需要备份的其他文件，堪称小型私人云盘。
• 批量管理很方便：支持瀑布流展示，多图选中一键删除，管理起来效率爆表。
• 安全放心：你可以自己设置访问密码，私密图片妥妥地保护好。

为什么它很合适#

说实话，图床这玩意儿，最怕的就是不稳定和复杂。托管在第三方平台，万一人家突然改规则，或者服务器宕机，图片没了，麻烦哪。云图完全属于你自己，自己掌控上传目录，数据安全稳稳的。

它不只是一个存放图片的地方，更是你照片和作品的“数字相册”。还记得朋友来问你，“能给我发点你上次旅行的照片吗？”你现在可以直接生成链接，一起分享那些美好时光，多方便。

此外，云图可以写自动脚本上传图片，实时调整展示效果，省力又好玩。

Docker部署#

云图用的是Docker容器技术，只要你有NAS或者一台小服务器，就能用下面的docker-compose文件一键部署：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

services:
  cloudimgs:
    image: qazzxxx/cloudimgs:latest
    ports:
      - "3001:3001"
    volumes:
      - ./uploads:/app/uploads:rw
    restart: unless-stopped
    container_name: cloudimgs-app
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=002
      - NODE_ENV=production
      - PORT=3001
      # - PASSWORD=your_secure_password_here  # 需要密码保护时开启

只需稍微替换一下ID，挂载目录指向你的照片存放位置，启动服务，分分钟搞定。用浏览器访问http://你的服务器IP:3001，就能看到简洁易用的界面。

体验云图#

还想感受？作者也提供了在线演示https://yt.qazz.site，密码是123456，不需要注册，直接体验。

想要了解更多，欢迎访问GitHub项目主页，一起参与开源社区，帮它变得更好！

这次跨 2026 新年的安排是两段：

开放自由注册：

• 时间：2025.12.31 18:00 — 2026.01.02 23:00
• 这段时间可以直接注册，不用等邀请。

全站种子 FREE：

• 时间：2026.01.03 — 2026.01.06
• 站里会有连续四天的 FREE 活动，体验会更轻松。

注册网址也在这儿，别找错：
https://pt.btschool.club/signup.php

• 中文名：比特校园
• 英文名：BTSCHOOL
• 暱称：学校 / 校园

它到底是个什么站？#

BTSCHOOL 属于那种“综合型”的站点，资源种类比较全：

• 电影、电视剧、动漫、纪录片、综艺
• 音乐、体育节目
• 软件、游戏
• 学习资料（这块是它的招牌）

说它“综合”，意思就是你不太容易在这里找不到想看的东西；说它“有特色”，意思就是它不是只靠影视撑场面，它更像把“学习”当成了自己的性格标签。

要特别留意#

最需要你注意的就是两点：

• 全站 HR（下载完不能立刻删）

• 有做种积分（关系到升级）

• 做种时间要求：
  一个种子下载完成以后，10 天内累计做够 20 小时
  这个要求不看大小，大文件小文件都一样按时间算。

• 有一种情况会更轻松：
  如果你对这个种子的上传量 大于 下载量，那就相当于你已经“帮了别人”，一般就直接过关，不用纠结那 20 小时。

• HR 未达标数 ≥ 10，账号可能会被 BAN（你可以理解成被封/被处理）

所以别抱着侥幸心理“我就下完删了应该没事吧”。很多人不是不懂，是忙起来忘了，一回头已经累积好几次不达标，真的很冤。

跨年这几天开放注册，再送上四天 FREE，像是在说：“新的一年想认真一点？进来坐坐。”

想注册的，把握好窗口期：
2025.12.31 18:00 — 2026.01.02 23:00
注册网址：https://pt.btschool.club/signup.php

家里用 NAS 的人，大多绕不开一件事：照片。手机越换越好，拍得也越来越多，孩子的成长、旅行的风景、一家人的合照，慢慢就堆成了一个巨大的相册库。放手机里怕丢，放网盘又担心隐私，放各种平台上更是有点“心里不踏实”。

我之前也用过群晖自带的 Photos。它有不少优点，比如自家应用、手机同步也方便。但真到“家庭一起看、一起分享”的场景，就会发现它更偏“按账户分开管理”，每个人的隐私是照顾到了，可一家人想把一些照片集中起来看，分享和查看就会有点费劲。

折腾来折腾去，很多人都会走到同一个选择上：PhotoPrism。它是个开源项目，可以用 Docker 部署在 NAS 或小主机上，用浏览器就能看相册，体验很舒服。有人甚至觉得，它拿来替代 Google Photos 也没啥问题。

项目地址和官网在这里：

• 开源项目： https://github.com/photoprism/photoprism
• 官方中文 Demo： https://demo-zh.photoprism.app/browse

PhotoPrism 用起来到底顺不顺？它能做哪些事？#

PhotoPrism 给人的感觉很直接：照片一多，它不慌，反而越用越有条理。

你把照片和视频放进去，它可以直接浏览，不太挑格式，也不用你为了能看去折腾各种转换。页面做得挺舒服，电脑、平板、手机浏览器都能自适配，坐沙发上拿手机翻相册也不会别扭。

它的搜索特别讨喜。照片多的时候，最怕的就是“我记得拍过，但死活找不到”。PhotoPrism 这块做得很强，你可以用各种条件去筛，找起来省心很多。鼠标放在照片上，还会显示一些照片信息，翻旧照片会有种“哎呀当时在这儿拍的”的感觉。

它还会帮你做一些“自动整理”的活儿，比如按内容、按地点去归类；有的人也很看重“人脸识别”，能认出家人朋友的脸，把同一个人的照片聚到一起。喜欢旅行的人会更有感觉，它带了高分辨率的世界地图，照片能按地点回忆起来，翻起来挺带劲。

照片信息这块也照顾得很全，会把照片里的信息整理出来，还能把不同来源的信息合在一起（有人从别的平台迁照片时会很在意这个）。另外还有一些用于筛选的图片属性，照片越多越能体会到它的好处。

你要是希望手机照片能自动备份到家里，PhotoPrism 也能配合做。它支持 WebDAV，所以手机端可以借助第三方工具把照片传回 NAS。很多人用得比较多的是 PhotoSync（iOS/Android 都有，但它是付费的，体验还行，就是不太支持中文），也有人用免费的 Syncthing，把手机相册同步到 NAS 的照片目录里，一次设置好就能长期用，而且不止同步照片，别的文件也能顺手一起同步。

安装这件事不玄乎：群晖、OpenWrt、Unraid 都可以#

PhotoPrism 最常见的玩法就是 Docker。好处很明显：不太挑系统，搬家也方便。下面把几种常见部署方式揉在一起讲清楚，照着你自己的环境选一种就行。

群晖上装：准备两个文件夹，填个密码就能跑起来#

群晖这条路很适合“想省事”的人。

Docker 先装好，接着在 Docker 目录下建一个 photoprism 文件夹，里面再放两个子文件夹，一个用来放配置，一个用来放照片：

• docker/photoprism/config（配置用）
• docker/photoprism/photos（照片用）

在 Docker 注册表里搜索 photoprism，下载最新镜像。镜像比较大，下载慢一点很正常，泡杯茶等它跑完。

创建容器时，存储空间那里把两个目录映射好：

• docker/photoprism/config → /photoprism/storage（放设置、缓存这些）
• docker/photoprism/photos → /photoprism/originals（放原图、原视频）

环境变量里加一个管理员密码：

• PHOTOPRISM_ADMIN_PASSWORD：你登录网页用的密码（别用中文）

保存并启动容器，等一会儿，用浏览器访问：

• http://群晖IP:你设置的端口

默认用 2342 端口，打开就能看到登录界面了。

手机照片怎么回家：PhotoSync 或 Syncthing，各有各好#

PhotoPrism 本身更像“相册管家”，手机端的自动备份要借助工具来完成。

PhotoSync 的路子比较省心，iOS 和 Android 都有，能在后台自动备份，配合 PhotoPrism 支持的 WebDAV 用起来挺顺。缺点也很直白：它是付费的，而且不太支持中文。

Syncthing 是另一种路子，免费，能把手机相册同步到 NAS 里的 photos 目录。设置会麻烦一点点，但只要耐心弄一次，后面就很省心。它也不只是同步照片，其他文件想同步也能顺手搞定。

一点很真实的总结：它适合“想把照片交给自己”的人#

PhotoPrism 这种工具最打动人的地方，不是炫技，而是踏实。

照片这东西太私人了，丢了心疼，泄露更闹心。用自托管的方式把照片放回家里，想看就打开网页，想给家人看就一起看，想整理就慢慢整理，那种“东西在自己手里”的安心感，很难用几句话说清。

如果你也遇到过“群晖 Photos 分享不太顺”“全家照片想集中管理”“不想再被云空间续费卡脖子”这种烦恼，PhotoPrism 值得试试。跑起来不难，体验也确实对得起大家口中的那句：成熟、舒服、能打。

这几年信息多到有点离谱。打开手机，一会儿是热点新闻，一会儿是推荐视频，一会儿又给你塞几个“你可能感兴趣”。看着看着就发现，自己不是在“看内容”，而是在“被内容牵着走”。

有时候我就想要一种更朴素的方式：我自己挑想看的来源，安安静静地把更新放在一个页面里；不被广告打扰，不被算法推着跑；最好还能免费、简单、别折腾服务器。

后来就遇到一个很对味的东西：osmos::feed。一句话就能概括它的气质：

这是一个可以直接跑在你 GitHub 仓库里的 RSS 阅读器，页面托管在 GitHub Pages，上新靠 GitHub Actions 自动更新。
没后端、没广告、没第三方跟踪，清爽得像刚洗完的玻璃杯。

下面就用最接地气的方式，聊聊它能干啥、怎么弄起来、怎么按自己的喜好打扮它。

这玩意儿到底是啥？能帮我解决什么事？#

osmos::feed 可以把你关注的 RSS 源聚在一起，生成一个网页。你打开这个网页，就能像刷“订阅列表”一样看更新。
你可以把它理解成：
你在 GitHub 上建一个“信息小屋”，小屋门口挂着你订阅的来源，屋里每天自己收快递（更新内容），你只要进去看就行。

你会得到一个什么样的页面？#

搭好之后，你会有一个网址，大概长这样：

1

https://<你的GitHub用户名>.github.io/<你的仓库名>/

打开它就是你的 RSS 聚合页。官方还有一些演示模板，比如暗色、亮色、甚至做成播客列表、YouTube 列表那种风格。

你不需要写后端，也不需要买域名。整个站点就是静态页面，托管在 GitHub Pages。

动手：把 osmos::feed 搭起来（照着做就行）#

1）用模板创建仓库#

去它提供的模板仓库，点“用模板创建新仓库”（Create a new repository from template）。

有个小细节要注意：仓库要选 Public（公开），因为 GitHub Pages 免费版对私有仓库有限制（一般人用公开最省心）。

创建完之后，你就有了自己的仓库，相当于把这套“房子的图纸”复制了一份。

2）打开 GitHub Pages，让网站能访问#

进你刚创建的仓库，找到：

Settings（设置） → Pages

在 Source 那里选择 gh-pages 分支并保存。
如果你一开始看不到 gh-pages，别急，刷新几下，通常过一会儿就会出现。

当页面提示你：

Your site is published at https://xxx.github.io/xxx

这就说明网站已经开门营业了。一般几十秒到一分钟。

3）改订阅源：把你想看的 RSS 填进去#

回到仓库根目录，找到文件：osmosfeed.yaml
点铅笔编辑。

你会看到类似这样的东西（这里用你自己的信息替换）：

1
2
3
4
5

cacheUrl: https://<github_username>.github.io/<repo>/cache.json
sources:
  - href: https://my-rss-source-1/feed/
  - href: https://my-rss-source-2/rss/
  - href: https://my-rss-source-3/feed

有两块内容要动：

（1）cacheUrl
把 <github_username> 换成你的 GitHub 用户名
把 <repo> 换成你的仓库名
还有一个小动作：如果它前面有 #，记得删掉 #，不然它等于没启用。

（2）sources
把默认的 RSS 地址换成你真正想订阅的地址。
一般网站会提供 /rss、/feed、/atom 这种链接。找不到的话，有时网页底部会写“RSS”，或者你用搜索引擎搜“网站名 + RSS”。

改完之后，拉到页面底部，点击 Commit changes（提交修改）。

提交后，GitHub Actions 会开始跑更新流程。等它跑完，你的网站内容就会刷新。

用起来是什么感觉？#

搭好那一刻，会有种很奇妙的掌控感。

你不是在某个平台里“被安排阅读”，而是在自己的网站里“按自己的口味吃饭”。你可以只订阅你真正想看的内容：某几个博客、某些新闻源、某些专栏作者。没有乱七八糟的推荐位，也没有“你可能喜欢”的干扰。

这玩意儿还有个很温柔的地方：
它不会催你，不会逼你“刷到停不下来”。你什么时候想看，什么时候打开；不想看，它就安静待着。

很多人买 NAS 说是为了“折腾”，但真落到日常需求，往往就两件事最实在：手机照片视频备份、出门拍的相机照片有个安全的落脚点。

尤其是 iPhone 用户，照片动不动就几百 G，手机空间被榨干，iCloud 还要月月交钱，心里总会冒出一句：

“要不我自己弄个家用备份仓库吧，踏实。”

NUC 适不适合做 NAS？#

结论很简单：非常适合做“家用备份型 NAS”。

• NUC 这种配置，跑个相册备份、文件共享、甚至顺手跑点小服务都很轻松
• 千兆网口配合家用宽带，家里用完全够
• 体积小、功耗低，放客厅角落也不碍事
• 真正要注意的反倒不是性能，而是硬盘和供电稳定（后面会说）

系统怎么选：省心路线 vs 折腾路线#

1）想省心、少踩坑：飞牛（很多人就是冲它的“照片备份”来的）#

不少人直接在 NUC 上装 飞牛，理由也很朴素：

• 手机端好用，能做远程/本地自动备份 iOS 照片
• 一般家庭要的功能它都给你整好了
• 用的人多，遇到问题也好搜
• 稳定性也还行，有人跑了几个月没啥毛病

照片备份这件事，讲真，大家折腾到最后，往往都会回到“能不能自动备份、别出幺蛾子”上。飞牛的优势就在这：把最常用的事做得顺手。

外网这块飞牛也有自带的远程方式（免费的速度可能一般，想快可能得付费），对“在外面看看照片、翻翻文档”这种需求够用。

如果你就想：装好就用、家里连 Wi‑Fi 自动备份、偶尔在外面查点东西
这条路最省心。

2）想更自由：Windows / Linux / Unraid 这种“自己搭”#

也有人直接：

• Windows10 + easytier：说是稳定，能用就行
• Arch / Ubuntu / Manjaro：自己配服务，想怎么折腾都行
• Unraid + Docker：能跑很多东西，再用 tailscale 做远程

这些方案的共同点是：
自由度高，但你得自己管：装什么、怎么配、怎么升级、怎么备份、坏了怎么救。

有人说得很真实：折腾半天把远程访问搞通了，最后发现外网其实用得不多。
在外面真要看视频，还受限于家里上行带宽、手机流量、跨网限速之类的，体验不一定爽。更多时候是：

在家把东西同步好，出门就安心用。

手机照片备份：真正舒服的体验是什么样？#

家用照片备份，理想状态就一句话：

手机连上家里 Wi‑Fi，照片自己往 NAS 里跑，你不用天天惦记。

很多人搞外网访问，最初是因为想“随时随地自动备份”。但现实里，在家自动备份就已经解决 80% 的焦虑：

• 你回家就充电
• 手机上照片开始同步
• 你刷会儿短视频，备份就悄悄完成了

外网备份当然也能做，但它不是必需品，更多是“锦上添花”。

外网访问怎么搞：几条路的真实感受（不吹不黑）#

外网访问这块，大家讨论最多的就是几种方式。这里把“优点/麻烦点/适合谁”讲清楚。

✅ 方案 A：用 IPv6 + DDNS（很多人用得最爽）#

有的人家里宽带直接给 IPv6，这条路就很香：

• 设备“直连”，速度可以跑满家里上行（比如 50Mbps 这种）
• 不用额外买服务器
• 成本低，体验好

但它也有个很现实的尴尬：

• 外面很多公共 Wi‑Fi 不给 IPv6
• 你可能得用手机 5G 才顺

如果你平时外网访问不多，这个影响也不大。

✅ 方案 B：Tailscale（省心穿透，很多人推荐）#

这玩意的优点在于：

• 真的省事，装上就能用
• 不用自己一个端口一个端口去映射
• 双栈支持，很多情况下速度也不错

但它的特点也得接受：

• 每个设备都得装客户端
• iOS 端有的人还遇到“需要外区账号下载”的麻烦（看你具体情况）

适合那种：

家里电脑、手机、平板都愿意装一个客户端，换设备也不嫌麻烦的人。

✅ 方案 C：VPS + frp / nps / easytier（能用，但要你自己养）#

优点：

• IPv4 环境也好使
• 有些场景外部设备不用装客户端

麻烦点：

• 得买 VPS（花点钱）
• 配置、维护要自己来
• 一不留神就变成“我在给自己上班”

有的人就是喜欢这种“掌控感”，也有人弄完一次就发誓再也不碰。

⚠️ 方案 D：Cloudflare Tunnel（有人说能用，但体验一般）#

讨论里不少人提到：

• 国内用起来可能 卡、慢
• 勉强能用，但别抱太高期望

如果你对速度没要求，只是偶尔连一下拿个文件，倒也不是不能凑合。

硬盘怎么接：别让“省事”变成“省出事故”#

NUC 做 NAS，最容易踩的坑不是系统，是硬盘连接方式。

有人用过“NUC 夹着两个移动硬盘”这种搭法，跑一年挺稳；也有人三个月坏两块盘，直接劝退。这里的关键点其实就两个字：供电。

大家踩过的坑总结一下：

• USB 外接硬盘最怕供电不稳
  断电、瞬断、接触不良，最伤盘
• 3.5 寸大硬盘最好用独立供电的硬盘盒/硬盘柜
• 写数据的时候别碰它、别挪它，震动也会影响（机械硬盘真的娇气）
• 外接方案没有“保险”，本质还是：

  鸡蛋放一个篮子里

如果你要放的是“全家照片视频”这种东西，建议你心里有个底：

• 单盘可以用，但得有第二份备份
• 真重要的东西，别指望“永远不坏”

有的人就很清醒：自己这么搭可以，但重要数据还有别处备一份，心里才踏实。

一套更像“过日子”的建议（按你这个需求）#

你这台 NUC 的定位，其实很明确：家用照片视频备份 + 随手存相机照片。建议你按这个思路走：

• 系统选一个你能长期用下去的
  想省心就上飞牛，想折腾就上 Linux/Unraid/Windows 自己搭
• 先把“回家自动备份”做起来
  这一步完成后，你会明显轻松很多
• 外网访问别一开始就把自己搞累
  家里有 IPv6 就用 IPv6 + DDNS
  没有就 tailscale（图省事）
  真要折腾再上 VPS/frp 这一套
• 硬盘别抠门在供电上
  机械盘尽量独立供电，少用那种“随手一个 USB 线就上”的方式
• 重要数据要有第二份
  你可以是另一块盘、另一台机器、或者别的备份方式
  反正别让“唯一一份”躺在同一个地方

写在最后：NAS 这东西，别被“折腾氛围”带跑偏#

很多人一开始玩 NAS，脑子里都是远程访问、穿透、容器、各种高级玩法。折腾很爽，但对大多数家庭来说，真正让人舒服的其实是这种感觉：

手机照片不再担心丢
空间不再天天报警
出门拍的照片有地方放
这台小盒子安安静静在角落干活，几乎没存在感