把副屏拿来显示桌面壁纸，或者只是拖一个聊天窗口过去，利用率其实很低。副屏更适合的角色是个人信息终端：把时间、天气、待办、日历、系统状态和消息提醒集中到一个常驻面板，抬眼就能看到，不用反复切换窗口。这篇文章会按我实际搭建的顺序，拆解如何把一块普通副屏变成信息终端，包括需求取舍、三种实现路径、起步实操、数据接入、资源占用和常见问题排查。适合正在用双屏，或者手里多了一块闲置屏幕的人参考。
先说结论：这类改造不需要特别贵的硬件，也不需要很强的编程基础。大多数情况下，一个浏览器页面加几个本地脚本就能把核心场景跑起来。真正花时间的，不是技术，而是想清楚“哪些信息值得长期放在副屏上”。
1. 先想清楚你的副屏到底要放什么信息
很多人拿到副屏后，第一反应是“先放个壁纸，再拖几个窗口过去”。这个思路问题不大，但效率很低。因为副屏的位置通常偏离视线中心，适合放不需要频繁操作、但需要频繁看一眼的信息。如果只是放聊天窗口，你会发现它要么被各种消息刷屏，要么长期被空白状态占着。
1.1 信息挑选原则：更新频率和使用频率要分开看
判断一个信息适不适合上副屏，我一般拆成两个维度：更新频率和使用频率。
- 更新频率高，但不需要响应的，适合放。比如时钟、天气、系统温度、CPU 占用、内存占用。
- 更新频率中，需要偶尔响应的，也适合放。比如待办事项、日历日程、邮件标题、群消息提醒。
- 更新频率低，但需要认真阅读的，不建议放。比如长文章、文档、代码、设计稿，这类内容更适合在主屏打开。
另一个判断标准是“眼睛扫一眼能否获取全部信息”。副屏信息终端做得好的，基本都满足这个条件：你只用余光扫一下，就知道时间、天气、待办数量，而不是盯着屏幕找数字。
1.2 根据屏幕形态决定布局
副屏有横屏、竖屏和触屏三种常见形态。先决定形态，再决定布局。
横屏副屏适合做“总览面板”。可以把时间放在左上，天气放右上，中间放日历或待办，底部放系统监控。这种布局的好处是信息横向分布，眼睛左右扫动即可。
竖屏副屏适合做“任务流面板”。因为竖向排列更符合任务列表的阅读习惯，你可以从上到下依次安排：顶部时间天气，中间待办和日程，底部音乐控制和快捷按钮。竖屏还有一个好处，就是消息预览不容易遮挡其他信息。
触屏副屏则要额外考虑交互区域大小。不要放太小的按钮，至少保证手指或触控笔能准确点选。如果你不打算买触屏，也完全没关系，信息终端大部分时间只是“看”，而不是“点”。
1.3 一个普通横屏副屏的信息配置表
我给一个自己常用的默认配置，仅供参考：
| 区域 | 信息内容 | 建议更新频率 | 是否必须实时 |
|---|---|---|---|
| 左上 | 日期时间 | 每秒 | 是 |
| 右上 | 天气 | 每 10-30 分钟 | 否 |
| 中间 | 日历/待办 | 每 5-10 分钟 | 否 |
| 左下 | 系统监控 | 每 2-5 秒 | 是 |
| 右下 | 音乐播放/快捷操作 | 实时 | 否 |
注意这个表格不是标准答案。如果副屏是竖屏，优先级会变成：时间、待办、提醒，系统监控可能直接去掉。信息项越少，越容易维护。
2. 三种实现路径：浏览器面板、桌面小组件、自建 Dashboard
确定信息内容后，下一步是选实现方式。市面上的方案大致分三类：浏览器全屏页面、桌面小组件工具、自建本地 Web Dashboard。三者各有适用场景，选错了后期会很痛苦。
2.1 方案一：浏览器全屏页面
优点是对跨平台最友好。Windows、macOS、Linux 都有浏览器，你只需要写一个 HTML 文件，或者直接打开一个现成的在线面板，按 F11 全屏即可。
缺点是浏览器本身有一定资源占用，而且如果你习惯开大量标签页，副屏页面很容易被误关。解决办法是使用浏览器的“应用模式”，把页面独立成一个类似桌面程序的窗口，减少标签误操作。
这个方案适合新手快速验证，也适合不想写太多代码的人。先看效果，再决定要不要换更复杂的方案。
2.2 方案二：桌面小组件工具
桌面小组件工具指的是能在桌面上渲染时钟、天气、系统监控条的那类工具。Windows 上常见的是 Rainmeter，macOS 上有 Übersicht，Linux 下常见的是 Conky。它们的特点是本地运行、资源占用相对低、样式高度可定制，但学习曲线也比浏览器方案高。
如果你只是想要一个系统监控面板，这类工具很合适。它们可以直接读取 CPU、内存、磁盘、网络等系统数据，不用自己写接口。但如果你要接入待办、日历、邮件这类业务数据，还是要额外写插件或脚本。
这类工具通常适合“单屏使用”，放到副屏上也没有问题，但要确认它支持指定输出位置和尺寸。有些小组件是按主屏分辨率设计的，放到副屏上会出现字体模糊或布局偏移。
2.3 方案三：自建本地 Web Dashboard
自建 Dashboard 是最灵活，也是后期维护成本最高的方案。你可以用 Node.js、Python 或任意后端语言起一个本地服务，前端用 HTML/CSS/JavaScript 展示数据，后端定时抓取天气、日历、待办、系统信息，再通过接口推给前端。
这种方案适合长期使用的人。因为数据源一旦标准化，后续加信息块就是加一个模块的事。缺点是前期搭建时间较长，涉及服务管理、接口鉴权、失败重试等一堆问题。
我一般建议：如果只是学习或短期使用，浏览器方案足够；如果确认要长期使用，并且有技术基础，可以直接自建 Dashboard。桌面小组件工具则适合夹在两者之间的人。
2.4 怎么选
| 维度 | 浏览器页面 | 桌面小组件 | 自建 Dashboard |
|---|---|---|---|
| 上手难度 | 低 | 中 | 高 |
| 系统资源占用 | 中 | 低 | 可控，看实现 |
| 数据接入能力 | 依赖在线服务 | 偏本地系统 | 最强 |
| 样式定制 | 高 | 高 | 最高 |
| 维护成本 | 低 | 中 | 高 |
| 适合人群 | 新手、临时使用 | 系统监控玩家 | 长期自用、开发向 |
选型时不要只看功能列表，还要看你的使用频率和维护意愿。一个三天打鱼两天晒网的项目，不如先用浏览器方案跑通，后面再加码。
3. 起步实操：从全屏浏览器仪表盘开始
下面按“最小可运行”的顺序带你跑通一个副屏信息终端。先不接天气、不接待办 API，只做最基础的时间和待办展示，确认流程没问题后再慢慢加功能。
3.1 先准备环境和目录
准备一个文件夹，例如D:\dashboard，在里面创建index.html。如果你的副屏是横屏，就按横屏布局写；如果是竖屏，把页面宽度限制在副屏分辨率以内。
文件夹路径一定不要带特殊字符和空格，后续做开机自启动时会省很多麻烦。如果你在 macOS 或 Linux 上操作，同理，建议路径用纯英文。
3.2 做一个最小仪表盘页面
这是一个非常简单的模板，只展示时间和待办列表。你可以先复制到本地看效果，再按需要修改。
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>副屏信息终端</title> <style> body { margin: 0; padding: 24px; background: #0f1115; color: #e6e6e6; font-family: "Microsoft YaHei", "PingFang SC", sans-serif; } .grid { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; height: calc(100vh - 48px); } .card { background: #1b1e27; border-radius: 12px; padding: 24px; } .time { font-size: 48px; font-weight: bold; } .date { margin-top: 8px; font-size: 18px; opacity: 0.7; } .todo li { margin: 8px 0; font-size: 18px; } </style> </head> <body> <div class="grid"> <div class="card"> <div class="time" id="time">--:--:--</div> <div class="date" id="date"></div> </div> <div class="card"> <h2>今日待办</h2> <ul class="todo" id="todo"> <li>示例任务：整理周报</li> <li>示例任务：检查副屏布局</li> </ul> </div> </div> <script> function updateTime() { const now = new Date(); document.getElementById('time').textContent = now.toLocaleTimeString('zh-CN'); document.getElementById('date').textContent = now.toLocaleDateString('zh-CN', { weekday: 'long', year: 'numeric', month: 'long', day: 'numeric' }); } setInterval(updateTime, 1000); updateTime(); </script> </body> </html>这个页面用 CSS Grid 分成左右两栏，左侧显示时间和日期，右侧显示待办。时间每秒刷新一次，待办目前还是写死的文字，后续可以通过接口动态读取。
为什么要先做这样一个小页面？因为副屏信息终端最怕“一上来就图大而全”。先把基础布局跑通，再往里面填真实数据，碰到问题也好定位。
3.3 让浏览器开机自动打开到这个页面
在 Windows 上，最直接的办法是把一个快捷方式放进“启动”文件夹。
步骤是：先在桌面建立一个 Chrome 或其他浏览器的快捷方式，然后修改快捷方式的“目标”路径，在浏览器路径后面加上页面路径。例如：
"C:\Program Files\Google\Chrome\Application\chrome.exe" --app=file:///D:/dashboard/index.html --window-position=1920,0 --window-size=1920,1080注意：--window-position和--window-size是否生效，取决于浏览器版本和显示配置，第一次设置时不一定能完美定位到副屏。更稳的方法是把页面打开后按 F11 全屏，让浏览器自动占据当前屏幕。如果你有多块屏幕，建议在 Windows 的“显示设置”里确认副屏在左侧还是右侧，再调整窗口位置参数。
你还可以用“应用模式”启动页面，这样浏览器不会显示标签页栏、地址栏，看起来更像一个桌面程序。不同浏览器的启动参数有差异，落地时以你安装的浏览器版本说明为准。
3.4 验证和调整
页面能打开后，做三个验证：
- 时间是否每秒更新，日期是否显示正确。
- 页面是否自适应副屏分辨率，没有出现横向滚动条。
- 副屏是否处于“扩展”模式，而不是“复制”模式。
Windows 下按Win + P选择“扩展”，macOS 下在显示器设置里选择“扩展显示”。如果副屏和主屏显示同样内容，说明当前是复制模式，需要切换。
调整阶段最常遇到的问题是字体太小或太大。这个不要急着改代码里的font-size，先确认副屏的缩放比例。Windows 中如果副屏分辨率比主屏低，系统可能会按 100% 或 125% 缩放，导致字体看起来偏小或偏大。先到“显示设置”里确认每个显示器的缩放比例，再回代码里调字号。
4. 进阶扩展：把待办、日历和消息通知接进来
基础页面跑通之后，就可以考虑接入真实数据了。这个阶段的目标不是把所有信息都接上，而是先接一个你最依赖的数据源，然后逐步扩展。
4.1 先接一个本地 JSON 接口
假设你有一个待办数据接口，返回格式大概是这样：
{ "todos": [ { "id": 1, "title": "准备周会材料", "done": false }, { "id": 2, "title": "回复项目邮件", "done": true } ], "updated_at": "2025-01-01T09:00:00+08:00" }在 HTML 页面里，可以用fetch定时读取这个接口，再渲染到待办列表里。下面是一个思路示例：
async function loadTodos() { try { const res = await fetch('http://localhost:3000/api/todos'); const data = await res.json(); const ul = document.getElementById('todo'); ul.innerHTML = ''; data.todos.forEach(item => { const li = document.createElement('li'); li.textContent = item.title; if (item.done) { li.style.opacity = '0.4'; } ul.appendChild(li); }); } catch (err) { console.error('加载待办失败', err); } } // 每 5 分钟刷新一次待办 setInterval(loadTodos, 5 * 60 * 1000); loadTodos();这里先不要纠结接口是否真实存在，而是先理解流程：前端定期请求接口，拿到数据后更新 DOM。这样后续你无论接什么服务，只要对方能输出 JSON，你就能把数据搬到副屏上。
4.2 用轮询还是长连接
信息服务常见的更新方式有两种：轮询和长连接。
轮询就是每隔一段时间问一次接口：“有更新吗？”优点是实现简单，适合信息变化不频繁的场景。缺点是有延迟和多余的请求。对于副屏信息终端，天气、日历、待办这类数据用轮询完全够用。
长连接则是服务器主动推送消息给前端，适合聊天消息、邮件到达提醒等需要即时响应的场景。例如 WebSocket 或 Server-Sent Events。缺点是实现更复杂，本地服务要维护连接状态，还要处理断线重连。
我建议先不要上长连接。默认的更新频率可以先这样设：系统时间每秒，系统监控每 2-5 秒，天气每 10-30 分钟，待办和日历每 5-10 分钟，消息提醒如果有独立推送再单独处理。轮询间隔不是越短越好，间隔太短会增大网络请求和电量消耗，也会触发接口限流。
4.3 通知与提醒
副屏的一个重要价值是“提醒”。但提醒也要克制，否则会变成新的干扰源。
如果是待办提醒，建议只显示“标题 + 截止时间”，不要显示大段备注。如果是日历提醒，可以在事件开始前 10 分钟或 30 分钟弹出卡片，并伴随一个低频声音提示。如果是即时消息提醒，更推荐只显示“来源 + 摘要”，而不是完整聊天内容。
实现方式可以有两种：一种是在 Dashboard 页面内部做，当数据更新时检测到新增事件，就播放一段短音频或显示一个弹层；另一种是使用系统通知 API，让副屏页面调用浏览器通知权限。两者都能用，关键是提前把“什么算提醒、提醒持续多久、是否需要手动关闭”想好。
4.4 安全与隐私边界
副屏通常长时间开着，存在被别人看到的风险。不要在上面显示完整邮件正文、密码、验证码、密钥或敏感文档。使用服务接口时，也尽量不要把 API Key 直接写在前端 HTML 里。如果只是本地自用，可以接受一定程度的简化，但也要注意：
- 本地服务只监听
127.0.0.1，不要暴露到局域网。 - 接口返回数据时，只把前端需要的字段返回，不要返回整个数据库。
- 定期检查自己写的轮询脚本，避免请求积累导致接口被限流。
这个环节不太起眼，但长期使用后反而最值得坚持。
5. 竖屏副屏的信息密度与布局优化
很多人的副屏是小尺寸便携屏，竖起来放更省空间。竖屏信息终端有天然优势，但也有自己的布局陷阱。
5.1 竖屏为什么适合信息终端
竖屏的长宽比大约是 9:16，非常适合展示从上到下的信息流。比如：
- 时间 + 日期 + 天气
- 今日待办
- 日历日程
- 邮件 / 消息摘要
- 音乐控制
这种布局和手机上常见的桌面小组件类似，眼睛扫一眼就能从上到下完成信息获取。相比横屏，竖屏对“列表型信息”的展示效率更高。缺点是横向空间有限，不能放太多并排卡片，否则每个卡片都会挤得很窄。
5.2 三段式布局：顶部状态、中部任务、底部控制
我比较推荐竖屏信息终端采用三段式布局。
顶部放“状态信息”：时间、日期、天气、系统监控。这些信息更新频率可以各有不同，但都不需要交互，适合固定在最上方。
中部放“任务信息”：待办、日历、邮件摘要。这是你每天都要看的内容，应该占最大面积。每一条只显示一行到两行，标题过长时用省略号截断，避免撑破布局。
底部放“控制信息”：音乐播放控制、快捷按钮、开关。如果你不是触屏，底部区域通常只能看不能点，那就可以减少控制类信息，换成实时数据图，比如 CPU 趋势或网络流量。
为什么这样分？因为人的视觉动线是从上到下。顶部状态信息只要扫一眼，中部任务信息需要花几秒理解，底部控制信息是偶尔操作。把交互频率高的信息放底部，不容易遮住主要内容。
5.3 信息过密时怎么取舍
竖屏看起来能放很多信息，但信息密度过高时，副屏会变成“第二个任务管理器”，反而让人焦虑。
取舍标准可以参考这几条：
- 如果某个信息一周内没有产生一次实际行动，建议去掉。
- 如果某个信息更新频率很低，且你不需要回头查看，也可以去掉。
- 如果某个信息需要放大才能看清，说明它不适合常驻副屏，点击进入主屏查看更合理。
- 如果某个信息只有少量数字，但需要占一整块卡片，可能是在浪费空间。
更好的做法是给信息块设置“展开/折叠”状态。默认只显示核心摘要，点击后进入详细视图。副屏信息终端的核心不是“多”，而是“准”。
6. 资源占用与稳定性：别让信息服务拖累主屏
副屏信息终端通常要长时间运行，资源占用和稳定性比功能花哨更重要。一个天天崩溃的信息终端，还不如不放。
6.1 资源占用怎么看
先看三块：CPU 占用、内存占用、网络请求频率。
浏览器全屏页面在空闲时通常比较省资源，但如果页面里加了复杂的 CSS 动画、大尺寸背景图或者高频刷新，CPU 会明显升高。桌面小组件工具有的会常驻后台，也需要留意内存占用。自建 Dashboard 如果用了 Python 或 Node.js 定时任务，还要看脚本本身的资源消耗。
排查时不要凭感觉，直接看任务管理器或系统监视器。排序后找到进程名，看它占了多少 CPU 和内存。如果信息终端页面占到 10% 以上 CPU，就要注意了。
我建议一开始就跑一个“最小版本”跑 24 小时，再检查资源占用。如果稳定，再逐步加信息块。不要第一天就塞满所有功能，出了问题很难定位是哪个模块导致的。
6.2 稳定运行的关键设置
有几个设置非常影响稳定：
- 系统睡眠和显示器关闭。副屏信息终端需要保持常亮，建议在电源设置里关闭“允许关闭显示器”或设置为“从不”。如果你不在电脑前，可以关闭副屏，不需要 24 小时亮着。
- 浏览器自动更新。有些浏览器更新后会自动重启，导致副屏页面丢失。可以看情况关闭自动更新，或者把页面加入自启动恢复。
- 任务计划。如果是自建服务，建议设置开机自启和崩溃重启。Windows 可以用“任务计划程序”，macOS 可以用 launchd，Linux 可以用 systemd。不同系统的管理方式不一样，使用时要先确认自己的系统。
还有一个容易被忽略的问题：副屏的连接线缆。如果用的是老式 HDMI 线或转接线，可能因为接触不良导致副屏偶尔黑屏。这时不要急着改配置，先检查线材和接口。
6.3 断网与异常降级
信息服务最怕断网。如果 Dashboard 页面完全依赖某个在线 API，网络一断，副屏就会显示空白或报错。
更稳妥的做法是“缓存降级”。每次请求成功后，把数据保存在本地文件或 localStorage 里。下次请求失败时，先用上一次的数据渲染，再在页面角落显示“数据可能已过期”。这样即使断网，时间、日期和最近一次待办仍然可见。
异常降级也要考虑接口返回异常的数据。比如天气接口返回了null，前端不能直接渲染成 undefined，而是显示一个占位符。数据不完整时，不要让整个页面闪动或报错。
7. 常见问题排查：先看现象，再看链路
最后整理一份排查思路。副屏信息终端出现问题时，不要一上来就改代码，先按规律排查。
7.1 副屏不显示或分辨率不对
先确认操作系统是否识别到第二块屏幕。Windows 下按Win + P选择“扩展”，如果副屏仍然不亮，检查线材、接口、显示器输入源。
如果副屏亮了但分辨率不对，先看“显示设置”里能否识别到正确分辨率。很多便携屏默认不开启最佳分辨率，需要在驱动或系统设置里调整。如果字体模糊，优先看“缩放比例”，而不是代码里的字号。
7.2 页面黑屏、白屏或卡住
页面黑了，先确认是显示设置问题，还是页面本身崩溃。比如按一下主屏，看主屏是否还正常。如果主屏正常，副屏黑屏且无信号，大概率是线材或显示器问题。如果副屏有信号但页面白屏，大概率是页面加载出错。
页面白屏时，按 F12 打开控制台，看有没有 JavaScript 报错。最常见的错误是接口请求失败、跨域被拦截、某个元素为 null。看到报错后，按“先看网络请求，再看控制台日志，最后看代码”的顺序处理。
7.3 数据不刷新或接口报错
数据不刷新，先看网络请求是否发出。浏览器开发者工具里的 Network 面板能看到请求状态。如果请求状态是 403 或 429，说明权限或限流问题。如果是 404，说明接口路径写错。如果是 CORS 报错，说明跨域配置没做好，可以在本地服务里加允许跨域的头。
如果是轮询脚本没有运行，检查setInterval是否被某些异常情况中断。页面被浏览器挂起或休眠时，定时器可能不准确，回退到页面重新加载后才会恢复。
7.4 性能过高与字体模糊
性能过高时，先找到占用高的进程。如果是浏览器页面，把高频刷新的模块拆出来单独测试，比如去掉系统监控动画，看 CPU 是否下降。如果下降明显，说明是动画或高频请求导致的问题，而不是页面本身。
字体模糊通常和系统渲染有关。Windows 下先检查“缩放比例”，尽量使用系统推荐的缩放。如果副屏分辨率太低，建议代码里使用相对单位，并减少小号字体。不要硬调显示分辨率，那样反而会让内容更模糊。
7.5 一个通用排查顺序
遇到任何综合问题时，可以按这个顺序看：
- 看现象：是黑屏、白屏、不刷新、卡顿还是资源占用高。
- 看输入：文件路径、接口地址、数据格式是否正确。
- 看环境：显示模式、缩放比例、电源设置、线缆、系统版本。
- 看参数：轮询间隔、并发请求数、窗口位置、自启动参数。
- 看工具本身：浏览器版本、桌面小组件版本、插件兼容性。
不要跳过第二步直接改代码。很多问题看起来像功能不支持，实际是路径写错、权限不足或输入格式不对。
最后留一句个人建议：先把“时间 + 一个真实数据源”跑稳定，再慢慢加其他信息块。副屏信息终端不是越复杂越好，而是越稳定越好。踩过几次坑后你会发现，真正让这个项目长期用下去的，不是好看的特效，而是它能在你抬眼的时候，准确给你需要的那几行信息。
