副屏这个东西很多人家里都有要么是淘汰下来的旧显示器要么是笔记本拆机屏要么是买来吃灰的 7 寸 HDMI 便携屏。大部分时候它就当一个扩展桌面用平时只显示一张壁纸等于屏幕在待命、信息没流通。这次我们把思路反过来把副屏变成一块常驻的“个人信息终端”专门用来显示时间、天气、日历、待办事项、系统监控、订阅流以及你自己内网服务的运行状态。这样既不占用主桌面空间又能随时扫一眼关键信息比“第二块壁纸屏”实用得多。这个改造思路并不复杂核心就三步第一步在本地或内网设备上跑一个 Web 仪表盘服务第二步让浏览器以全屏 kiosk 模式常驻在这块副屏上第三步把需要的数据通过接口或者数据源喂给页面。它不需要高端显卡也不需要复杂的三维渲染真正吃资源的部分很少成本主要集中在“一块能长时间开机的屏幕”和“一个能稳定跑服务的低功耗设备”。本文会把这套流程拆成可以直接落地的步骤包括软件选型、硬件准备、服务启动、页面配置、接口对接以及长期运行会遇到的常见坑。如果你手头正好有闲置显示器只差一个能跑起来的完整思路这篇文章可以直接收藏。先把判断标准给出来最低成本方案是旧笔记本或软路由加浏览器全屏模式更省电的方案是树莓派或类似单板计算机配一块小 HDMI 屏最省事的软件方案是先跑一个自托管仪表盘再逐步加模块。下面开始讲具体怎么做。1. 个人信息终端核心能力速览能力项说明主要功能时钟、天气、日历、待办事项、系统监控、RSS/订阅流、自定义信息面板硬件门槛闲置屏幕 低功耗主机或直接复用 Windows 副屏软件形态Web 仪表盘 浏览器 kiosk 模式或专用面板程序部署方式Docker Compose / 包管理器安装 / 浏览器全屏是否支持接口 API取决于所选仪表盘部分项目支持 HTTP 或 WebSocket 数据接入是否支持批量任务适合批量展示多个信息源不适合重型计算任务典型运行平台Linux 单板计算机、旧笔记本、Windows 副屏资源消耗轻量仪表盘通常占用内存较小具体数值按实际版本测试需要提前说明一点不是所有仪表盘都支持 API 推送。有些项目只是把链接和小组件渲染成静态页面有些则开放 HTTP 接口或 WebSocket允许外部数据实时刷新。选型的时候重点看三个能力数据能否自动刷新、模块能否自定义、是否支持 YAML 或 JSON 配置。这三个点决定了后续扩展的舒适度。2. 软件方案选型谁适合做仪表盘2.1 常见开源仪表盘下面列几个常见的开源方案。它们有一个共同特点最终都以网页形式呈现所以“能不能用”这件事主要取决于页面加载速度和配置灵活度。具体支持程度和版本细节以各项目官方文档为准。MagicMirror2一个模块化智能镜面/仪表盘项目基于 Electron有大量第三方模块社区生态比较成熟。适合树莓派、旧笔记本这类长期运行的设备界面风格偏“信息面板”。Dashy自托管导航仪表盘配置基于 YAML支持多页面、小组件和服务状态检测。适合把内网一堆服务入口聚合到一块屏上。Homepage偏现代风格的自托管仪表盘主打和常见服务集成界面干净加载速度快适合追求美观度的用户。Homer极简式静态仪表盘没有数据库写一个 YAML 文件就能跑起来适合不想折腾复杂配置的人。Glance偏“信息流”风格支持 RSS、天气、股票、视频频道等小部件适合做纯信息聚合屏。Grafana 数据源如果副屏主要用于监控内网服务器、NAS、网络状态Grafana 是更直接的选择但消耗资源也更高。2.2 按运行设备选择Windows 副屏直接用 Chromium 或 Edge 全屏访问本机仪表盘服务最省事但长时间开着会占用一定内存。树莓派或旧笔记本安装 Linux 后设置开机自动进入 kiosk 模式适合 7x24 小时运行。平板或闲置手机只要屏幕支持浏览器也能临时当信息终端用但充电策略和进程保活要额外处理。2.3 选型判断标准判断一个仪表盘是否适合做个人信息终端可以只看四个点。第一启动快不快第一次加载最好在 3 秒以内第二刷新稳不稳不会因为某一个接口超时把整个页面卡死第三配置改起来方不方便改一个模块参数后是否需要重启整个服务第四能不能离线纯本地数据在断网情况下能不能正常显示。把这四个点跑一遍基本就能判断这个方案值不值得长期用。3. 适用场景与使用边界个人信息终端解决的核心问题是“信息碎片化”。写代码、处理文档、开会前侧眼扫一下就能看到当前时间、待办事项、会议提醒和服务器状态不需要来回切换窗口。它也比较适合做数字相册、家庭共享面板、工作室数据屏和办公室值班信息屏。但它不适合做重交互、重计算。本质上它是一个单向展示面板最多加一个触控入口不要指望用它长时间跑视频、跑 3D 场景或作为远程桌面主力。另外如果屏幕亮度高、分辨率高功耗和发热会比想象中大长时间使用要考虑动态熄灭或待机策略。合规边界也要说清楚。把副屏变成个人信息终端涉及三类问题。数据来源合规方面天气、新闻、图片、字体、视频流等内容使用前要确认授权范围不要未经授权抓取或转售。隐私边界方面如果面板显示聊天记录、邮件、日历事项、服务器密钥这些就属于敏感信息不要让这些内容出现在公共场合更不要让内网页面暴露到公网。平台政策方面如果用于工作场景或公共区域展示要先确认是否符合公司信息安全要求。4. 环境准备与前置条件4.1 硬件层一块能长期开启的屏幕支持 HDMI/DP 输入即可。一台低功耗主机树莓派、旧笔记本、迷你主机都行或者直接复用主力电脑。电源线和网络连接建议使用有线网避免 WiFi 断流导致页面刷新失败。如果用的是拆机屏幕需要额外配一块驱动板确定驱动板支持当前分辨率后再接主机。4.2 系统层树莓派推荐装 64 位 Raspberry Pi OS或者其他 Debian 系 Linux。旧笔记本可以装轻量桌面环境例如 Xfce也可以不装桌面直接跑浏览器服务。Windows 副屏方案需要完整的桌面系统不用额外改造。4.3 软件层浏览器Chromium、Edge 或 Chrome 均可kiosk 模式用 Chromium 最省资源。运行环境如果仪表盘是 Node.js 项目需要先装 Node.js如果是 Go 项目需要对应二进制文件如果走 Docker需要 Docker 和 Docker Compose。依赖管理部分开源项目要求 npm install 或 pip install安装前认真看 README尤其注意 Node 版本和 Python 版本要求。4.4 网络层给仪表盘主机分配静态内网 IP方便浏览器长期访问。确定端口不会冲突8080、3000、7860 这类常见端口容易被占用。如果页面要从公网拉取天气或新闻 API确保 DNS 解析正常。如果要用 HTTPS内网环境可以用自签名证书但浏览器会有警告kiosk 模式下需要提前处理证书信任。5. 部署与启动方式5.1 方案一浏览器 kiosk 模式这是最快的一条路径。先把仪表盘服务跑起来然后让浏览器以 kiosk 模式全屏访问页面。在树莓派或 Linux 系统下可以用 Chromium 的全屏参数启动# Raspberry Pi OS 下启动 Chromium 全屏 kiosk 模式 # 实际地址按你的仪表盘服务地址调整 chromium-browser \ --kiosk \ --noerrdialogs \ --disable-infobars \ --disable-session-crashed-bubble \ --check-for-update-interval604800 \ http://127.0.0.1:8080需要注意不同 Linux 发行版中 Chromium 的命令名可能不同可能是chromium-browser也可能是chromium。启动后如果页面不是全屏或者出现了浏览器工具栏就说明 kiosk 参数没有被正确加载。Windows 下也可以用同样的思路把 Chrome 快捷方式的目标改成C:\Program Files\Google\Chrome\Application\chrome.exe --kiosk http://127.0.0.1:80805.2 方案二Docker Compose 部署仪表盘如果仪表盘项目提供了 Docker 镜像推荐用 Docker Compose 管理方便升级和回滚。下面是一份通用模板需要按实际项目替换镜像地址和配置路径services: dashboard: image: ghcr.io/your-org/info-terminal:latest container_name: info-terminal restart: unless-stopped ports: - 8080:8080 environment: - TZAsia/Shanghai - REFRESH_INTERVAL60 volumes: - ./config:/app/config - ./logs:/app/logs启动命令docker compose up -d docker compose logs -f使用 Docker 方案时要特别关注镜像的更新策略。很多开源仪表盘项目更新频率较高升级前先备份配置文件再拉取新镜像。restart: unless-stopped保证了系统重启后容器会自动恢复但前提是 Docker 服务本身已设置为开机自启。5.3 方案三系统服务开机自启如果你用的是 Linux 系统想让浏览器全屏启动变成一个可靠的服务可以写一个 systemd 单元文件。下面是一个通用模板[Unit] DescriptionInfo Terminal Dashboard Afternetwork-online.target [Service] ExecStart/usr/bin/chromium-browser --kiosk --noerrdialogs http://127.0.0.1:8080 Restartalways RestartSec10 Userpi [Install] WantedBygraphical.target保存为/etc/systemd/system/info-terminal.service后执行sudo systemctl daemon-reload sudo systemctl enable info-terminal.service sudo systemctl start info-terminal.service这个方案的优点是崩溃自动拉起开机自动进入仪表盘。缺点是首次进入桌面前可能会有几秒黑屏原因是图形会话还在初始化。5.4 验证是否启动成功启动完成后分三步确认。第一步在主机本机访问http://127.0.0.1:8080能看到仪表盘页面第二步在局域网另一台设备上访问http://主机IP:8080也能打开页面第三步确认浏览器全屏后没有地址栏、书签栏和标签栏。如果局域网访问失败优先检查服务监听地址是不是只绑定了127.0.0.1应该改成0.0.0.0。6. 功能搭建与信息模块配置6.1 设计信息终端布局一个适合个人使用的信息终端布局可以按视觉动线来设计。顶部放时钟、日期、天气和日历这部分是最常看的中间放待办事项、日程提醒和重要通知底部放系统监控、RSS 订阅流或服务状态。主色调用深色降低夜间亮度和长时间注视的疲劳感。6.2 典型 JSON 配置示例多数仪表盘项目支持 YAML 或 JSON 配置。下面是一份通用的 JSON 模板用于表达“我的页面有哪些模块、数据从哪里来”{ theme: dark, layout: single-column, modules: [ { type: clock, title: 当前时间 }, { type: weather, city: 默认城市, refresh_interval: 600 }, { type: calendar, source: webcal://your-calendar-url, max_items: 10 }, { type: rss, feeds: [ https://example.com/feed.xml ], max_items: 5, refresh_interval: 300 } ] }这份配置只是模板实际字段名和取值规则要以你选择的仪表盘项目为准。如果项目不支持refresh_interval这种字段建议用项目自己提供的刷新机制不要硬套。6.3 常见模块与数据源时钟模块本地时间通常不需要外部数据重点调整时区和 12/24 小时制。天气模块接入天气服务 API免费版一般够用。要注意刷新频率避免频繁请求导致限流。日历模块使用本地日历文件或 CalDAV 服务适合展示会议和待办。待办事项模块可以从本地 Markdown 文件、番茄钟工具或任务管理服务读取。系统监控模块通过本地部署的监控 Agent 上报 CPU、内存、磁盘、温度等指标。RSS/订阅模块拉取新闻源或博客源适合放在底部滚动展示。6.4 配置修改节奏第一次配置时不要一次性把所有模块都加上。先跑一个时钟和天气模块确认页面能正常加载、刷新正常再逐步加入日历、待办和监控。每次加一个新模块观察半小时确认没有内存持续上涨或接口频繁报错再继续下一个模块。这样能避免“页面崩了不知道是哪个模块导致”的情况。7. API 接口、批量刷新与自动化7.1 为什么需要 API仪表盘页面默认展示的是静态内容但实际使用中我们希望看到的是实时数据——服务器状态、当前网速、任务进度、排队数量等。这时候就需要仪表盘具备 API 接入能力。有些开源仪表盘自带插件市场可以直接连外部服务有些则需要你自己写一个小接口把业务数据推送或拉取到页面。7.2 一个通用推送脚本示例下面是一个用 Python 写的通用数据推送示例。它定期采集本机指标POST 到仪表盘的 API 端点。具体接口路径和字段要以实际项目为准import json import time import requests DASHBOARD_API http://127.0.0.1:8080/api/push def collect_metrics(): # 替换成实际的数据采集逻辑 return { module: system, cpu_usage: 42, memory_usage: 51, timestamp: int(time.time()) } def push_metrics(payload): try: response requests.post(DASHBOARD_API, jsonpayload, timeout30) return response.status_code 200 except requests.exceptions.RequestException as exc: print(fpush failed: {exc}) return False if __name__ __main__: while True: data collect_metrics() ok push_metrics(data) print(fpush status: {ok}) time.sleep(60)7.3 批量刷新设计当模块数量变多时不能用同一个刷新频率。合理设计是高频模块 10 到 30 秒刷新一次比如系统监控中频模块 5 到 10 分钟刷新一次比如待办和通知低频模块 30 到 60 分钟刷新一次比如 RSS 和天气。这样能显著降低接口负载和内存占用。另一个关键点是缓存。如果多个模块需要同一个数据源的数据不要让每个模块都独立请求一次而是统一拉取后缓存在服务端。比如同时有三个模块需要 CPU 占用率只采集一次分发给三个页面组件这样既节省资源也降低接口冲突概率。7.4 失败重试和降级接口请求失败了页面不能跟着崩溃。更稳的做法是请求失败时保留上一次正常数据并显示更新时间连续失败三次后模块状态变成“数据不可用”而不是一直转圈。重试间隔要加退避策略第一次 10 秒、第二次 30 秒、第三次 60 秒避免反复请求造成雪崩。8. 资源占用与性能观察8.1 资源占用波动大个人信息终端的资源占用差异非常大。轻量静态仪表盘可能只占几百 MB 内存而带大量动画、WebSocket 和持久连接的仪表盘可能占用明显更高。这里不给出固定数字因为实际占用取决于模型版本、模块数量、刷新频率和浏览器内核。更靠谱的做法是自己在设备上跑一轮测试记录单位时间内的平均内存和 CPU 占用再决定是否保留该方案。8.2 观察资源占用的方法在 Linux 主机上可以用以下命令观察资源占用htop free -m如果仪表盘是容器运行用 Docker 的统计命令会更直接docker stats浏览器页面的资源占用可以通过浏览器自带的任务管理器观察。Chromium 按Shift Esc可以打开自带任务管理器能清楚看到每个标签页占用的 CPU 和内存。8.3 降低资源占用的技巧第一关闭不必要的动画。信息终端最忌讳动画过多既占资源又容易分散注意力。第二减少模块数量。同屏展示的信息不是越多越好保留核心 5 到 8 个模块即可。第三延长时间轮询间隔。刷新越频繁资源占用越高。第四优先使用静态构建产物。如果仪表盘项目支持静态导出可以将生成结果直接放进 Nginx避免每次刷新都启动一次动态渲染。8.4 屏幕和功耗观察长时间运行的屏幕还要关注功耗。低亮度、深色主题、设置合理的自动熄屏时间都是降低功耗的手段。如果设备只是用来显示仪表盘可以在系统设置里关掉屏幕保护程序和自动休眠必要时用“不活动时保持亮屏”的配置。长期运行还要关注设备散热尤其是树莓派和旧笔记本这类被动散热的设备温度过高会影响稳定性。9. 常见问题与排查方法问题表现可能原因排查方向解决方法开机后没有全屏页面服务未启动或浏览器未设置自启查看 systemd 服务状态和日志设置服务自启检查浏览器启动参数页面长时间不刷新接口超时或轮询间隔太长查看接口返回和浏览器控制台增加失败重试缩短或错开轮询间隔内网其他设备打不开页面服务只监听了本机地址或防火墙拦截检查监听地址和防火墙规则将服务监听地址改为0.0.0.0开放对应端口浏览器显示证书或安全警告使用了自签名 HTTPS 证书检查证书有效期和信任列表在系统里导入证书或改用 HTTP 内网访问屏幕自动熄灭了系统电源管理设置检查系统休眠配置设置永不待机或使用模拟输入脚本页面出现乱码或数据错位编码问题或接口字段名不匹配检查接口返回格式和页面配置字段统一使用 UTF-8核对字段名和 JSON 结构日志增长速度过快日志没有轮转查看磁盘占用和日志目录按天切割日志限制保留条数升级后配置失效新版本改了配置格式查看项目 changelog 和迁移文档根据官方文档升级配置模板10. 最佳实践与使用建议第一第一次上手先做最小验证。不要一开始就追求“所有信息都在一块屏上”先跑通一条完整链路服务启动、浏览器全屏、页面显示、数据刷新。四个环节都通了再逐步增加模块。第二保留一套最小可运行配置。在折腾新旧模块或修改参数之前把当前能正常工作的配置复制一份。哪怕之后改崩了也能快速回滚到稳定状态。第三文件目录要清晰。模型文件、配置文件、输入素材、输出日志分别放不同目录避免升级时误删数据。推荐的目录结构是这样~/info-terminal/ ├── config/ │ └── dashboard.yaml ├── data/ │ └── cache/ ├── logs/ └── backup/第四批量任务和自动化脚本要加日志。信息终端通常会挂多个自动刷新任务每个任务都应该记录“上次成功时间”和“最近一次错误”。否则出问题时很难判断是哪个环节断了。第五接口服务要限制访问范围。如果仪表盘提供 API 接口只开放给内网设备不要直接暴露到公网。API 密钥和令牌也不要写进前端页面否则等于把凭据公开了。第六涉及人脸、声音、版权素材时必须确认授权。虽然这个场景主要是展示文字和图标但如果涉及图片、头像、摄像头画面依然要遵守授权规则。第七发布或商用前要做效果复核。公共区域的展示屏文字大小、背景色、信息刷新速度都需要实际跑一段时间验证不能只看截图效果。11. 总结与下一步如果你正好有一块闲置的副屏现在就可以按这个思路把服务跑起来。整个流程不需要复杂的硬件改造最省事的路径是在旧笔记本或 Windows 副屏上装一个轻量仪表盘再用浏览器全屏模式打开先让页面显示起来。最关键的是优先验证三个点服务能自启、页面能全屏、数据能自动刷新。三个点都通了这块屏就不再是壁纸屏而是一块真正有信息密度的终端屏。接下来你可以继续扩展的方向包括接入内网监控系统把服务器负载、NAS 温度和宽带实时流量显示出来接入日程和待办服务让副屏变成倒计时提示板如果屏幕支持触控还可以增加几个快捷入口按钮把它变成家庭或工作室的轻量控制面板。先跑通最小闭环再一步步加功能这个项目的完成度会超出你的预期。