很多人的副屏最终都变成了两种东西一个是不会动的壁纸一个是永远乱糟糟的备用窗口区。我自己也经历过这个阶段。刚多出一块显示器时第一反应是“终于可以一边写代码一边看文档了”后来发现文档窗口总是被聊天窗口盖住聊天窗口又总被终端盖住副屏不但没有提高效率反而成了一个专门用来“找窗口”的地方。后来换了一个思路不再把副屏当作主屏的扩展而是把它变成一台信息终端。它不负责给你提供操作空间只负责把那些需要持续关注、但不需要频繁操作的信息稳定地摆在你余光范围里。这个转变听起来不大实际体验却差很多。副屏从“第二块主屏”变成“状态可见层”之后你才真正开始用它。1. 先想明白副屏的定位不是“第二块主屏”而是“状态可见层”1.1 你需要的不是更多窗口而是减少切换成本大多数人添第二块屏幕理由是“终于可以同时看更多东西了”。这句话对却不完整。同时看到更多东西提升的只是“看到”这个动作本身真正影响效率的是“切换注意力”的成本。在主屏上你写代码、写文档、回消息、查资料窗口本来就多。当你把这些窗口再分一块到副屏上视觉空间是变大了但窗口之间的布局管理、焦点切换、滚动定位也变多了。尤其当副屏上同时堆着聊天、文档、文件管理器三种窗口时你每次需要用其中一个都要先找它在哪里。找窗口这个动作就是被新增的副屏放大的隐性成本。副屏作为信息终端正好绕开这个问题。它不需要你频繁地往上面拖窗口也不需要你记住哪个窗口在哪个位置。它只做一件事把一组固定信息以固定布局显示在那里。你不需要操作它只需要在需要的时候扫一眼。所以这里要做一个明确的定位调整副屏不是“第二个工作台”而是“状态可见层”。工作台是拿来操作的状态可见层是拿来“看”的。你把它当工作台它就会变成另一个窗口堆叠区你把它当状态可见层它才会真正减少你操作系统的次数。1.2 副屏信息终端的核心判断标准扫一眼能否获得状态怎么判断一个副屏信息终端做得好不好不需要看界面细节也不需要用复杂指标衡量。我习惯用一个很简单的测试你正在主屏写东西突然想确认“现在几点了”“今天下午有没有会”“构建是不是红了”眼睛从主屏移到副屏整个过程不超过一秒你能不能得到答案。如果看完副屏你还需要读一遍标题、找一遍内容、或者想一下“这个颜色到底代表正常还是异常”那说明它还不是一个合格的信息终端。信息终端追求的不是信息量而是“状态可知性”。这句话要再强调一遍副屏信息终端追求的不是信息量是状态可知性。它和大屏数据可视化不一样。数据大屏可以铺满两百个指标因为它的使用场景是“有人站在那里认真看”但副屏在你余光里你只会给它不到一秒的注意力。信息一多、字号一小、布局一乱就等于没有这块副屏。一个可行的做法是把副屏内容控制在“一屏能扫完”的密度。宁可少放三张卡片也不要为了填满屏幕而塞入一堆你根本不会看的数据。状态可见的前提是内容简单到被眼睛自动略过时仍然能抓住异常。2. 从需求反推内容别把壁纸和监控面板混为一谈2.1 三类最适合放副屏的信息哪些信息真正值得放在副屏上不是所有信息都适合。我的经验是它们通常具备三个特征低频变化、常驻可见、扫读即得。第一类时间、日历、待办。这几乎是副屏信息终端最稳的起点。日期、星期、当前时间、今日待办都是你每天会反复确认的信息。它们变化频率低不依赖外部服务即使其他数据源全部失效这块副屏也仍然有用。第二类开发状态、构建结果、服务器监控。这种信息很适合放在副屏尤其是团队开发或自己维护服务的人。它们的特点不是“需要一直盯着”而是“一旦异常需要尽早看见”。一块副屏上只显示“最近一次构建是否成功”“当前服务的错误数是否超过阈值”比放一整排复杂图表更实用。这里的关键设计是异常提示要做重正常时用灰色或绿色异常时用红色边框或者直接增大对应卡片的存在感。第三类订阅更新、邮件摘要、RSS 标题。你可以把每天会刷的信息源收敛成一个列表只显示标题和来源不点开、不收藏扫一眼就知道今天有什么值得看。这类信息的难点不在展示而在过滤。订阅源如果不经过筛选副屏上就会变成信息流瞬间失去“状态可见”的意义。这三类信息有一个共同点你一天可能会看它们很多次但每次只是确认状态不会在副屏上完成复杂操作。这正是信息终端和“第二操作区”的边界。2.2 一个四步拆解法目标、信息、形态、载体如果你不确定到底该在副屏上放什么我建议用下面这个四步拆解法它基本可以复用到任何个人信息终端场景。第一步确定副屏的位置和注视距离。副屏是放在正对面、侧面、还是桌子远端决定了字号和内容密度。如果你坐在离副屏一米外普通网页字号根本看不清信息越多越没用。先定物理位置再谈信息布局。第二步确定信息优先级。拿一张纸记录自己一周里每天会反复主动查看哪些信息时间、日历、待办、天气、构建状态、服务器负载、邮箱、订阅更新。然后做一个筛选只保留“一天超过三次、每次低于三秒”的信息。那些偶尔才看一眼的内容不值得占用副屏上的固定位置。第三步确定数据来源。对筛选出的信息逐项问一个问题数据能不能自动获取自动获取的依赖是什么比如时间不需要数据源待办如果来自某个任务管理器就需要它提供接口或文件构建状态则需要接入 CI/CD 的查询接口。自动获取的信息源越多系统的故障点就越多所以在一开始最好只保留一到两个自动数据源。第四步确定刷新频率和异常提示。不是所有数据都值得每秒刷新。时钟按秒刷新就够了构建状态每分钟刷新一次订阅列表十分钟刷新一次待办甚至可以只在页面加载时读取一次。对于异常类信息要做视觉强调不要让它淹没在一堆普通文字里。这四个步骤的优先级很明确先解决位置和阅读效率再决定放什么内容最后才考虑技术实现。很多人做副屏信息终端一上来就研究技术选型结果忘了自己到底要拿它看什么。2.3 不适合放副屏的信息类型把副屏定位成信息终端后也要清楚它不适合放什么。需要大量输入和操作的界面比如聊天窗口、IDE、设计软件不适合放副屏。你放在副屏上的东西越需要操作就越容易把你拉回主屏的窗口管理逻辑里信息终端的设计就失效了。需要连续阅读的长文也不适合。副屏通常在侧面距离和角度都不适合长时间阅读它更适合展示“标题级”信息而不是替代主屏完成阅读任务。更重要的是能让你的注意力被“吸走”的内容比如社交信息流、短视频推荐、新闻瀑布流也不适合放副屏。信息终端和娱乐屏的差别在于前者是被动展示状态后者是主动消费内容。如果你发现自己在副屏前刷了三分钟那么这个副屏的定位已经偏了。3. 最小可用方案用一个网页把副屏变成信息终端3.1 为什么先用网页方案而不是装一堆桌面小组件想清楚放什么内容之后接下来才是技术方案。我不建议一开始就装一堆桌面小组件也不建议直接上重型自托管监控平台。那个思路听起来很酷但维护成本会迅速超过收益。一个更稳的切入点是用网页。网页方案的好处是跨平台、好调试、可复用。你在一台正常显示器上把 HTML 页面调好然后同样的页面可以跑在旧手机、旧平板、树莓派或者任何带浏览器的设备上。改样式只需要改 HTML 和 CSS刷新浏览器就能看到效果不需要重新打包、重新安装。而且网页方案可以从一个非常小的闭环开始一个 HTML 页面一个 JSON 数据文件一个本地 HTTP 服务。先跑通“显示数据”这条链路再逐步增加数据源。这个路径足够简单也足够稳。3.2 用一个 HTML 面板把数据展示出来这里给一个最小可用的示例。它不依赖任何外部接口只是从同一个目录下的data.json读取数据然后渲染到页面上。这样你可以先把“数据文件 → 页面展示”的链路跑通后续再替换真实数据源。data.json可以先用这样一份结构{ todo: [写周报, 提交代码, 预约牙医], rss: [ { title: 示例标题一, link: https://example.com/1 }, { title: 示例标题二, link: https://example.com/2 } ] }面板页面的核心结构大致如下!DOCTYPE html html langzh-CN head meta charsetUTF-8 titleDesk Info Panel/title style :root { --bg: #111; --card: #1c1c1c; --text: #eee; --muted: #888; } * { box-sizing: border-box; margin: 0; padding: 0; } body { background: var(--bg); color: var(--text); font-family: system-ui, sans-serif; } .grid { display: grid; grid-template-columns: repeat(2, 1fr); gap: 16px; padding: 20px; height: 100vh; } .card { background: var(--card); border-radius: 12px; padding: 20px; overflow: hidden; } .clock { font-size: 64px; font-weight: 700; } .date { font-size: 28px; color: var(--muted); } .card h3 { font-size: 18px; color: var(--muted); margin-bottom: 8px; } ul { list-style: none; } li { padding: 6px 0; border-bottom: 1px solid #2a2a2a; font-size: 16px; } .error { color: #ff6b6b; font-size: 14px; } /style /head body main classgrid section classcard div classclock idclock--:--:--/div div classdate iddate----/div /section section classcard h3今日待办/h3 ul idtodo-list/ul /section section classcard h3订阅/h3 ul idrss-list/ul /section section classcard h3运行状态/h3 p iddata-status等待数据源.../p /section /main script function escapeHtml(str) { return String(str).replace(/[]/g, function (c) { return { : amp;, : lt;, : gt;, : quot;, : #39; }[c]; }); } function refreshTime() { const now new Date(); document.getElementById(clock).textContent now.toLocaleTimeString(zh-CN, { hour12: false }); document.getElementById(date).textContent now.toLocaleDateString(zh-CN, { year: numeric, month: long, day: numeric, weekday: long }); } async function refreshData() { try { const res await fetch(./data.json, { cache: no-store }); if (!res.ok) throw new Error(HTTP res.status); const data await res.json(); const todoHtml (data.todo || []) .map(item li${escapeHtml(item)}/li) .join(); document.getElementById(todo-list).innerHTML todoHtml; const rssHtml (data.rss || []) .map(item lia href${escapeHtml(item.link)} target_blank${escapeHtml(item.title)}/a/li ) .join(); document.getElementById(rss-list).innerHTML rssHtml; document.getElementById(data-status).textContent 数据源正常; } catch (err) { document.getElementById(data-status).textContent 数据源不可用 err.message; } } refreshTime(); setInterval(refreshTime, 1000); refreshData(); setInterval(refreshData, 30000); /script /body /html这个面板做了几件事显示时钟和日期读取同级目录的data.json把待办和订阅列表渲染出来数据源出错时在“运行状态”卡片里给出提示。它不算漂亮但足够稳定而且可以继续演化。这里有一个关键设计就是把“获取数据”和“展示数据”分开。数据更新逻辑不放在页面里而是由外部脚本生成data.json。页面只负责读取文件、渲染结果。这样数据源挂了页面不会白屏而是明确告诉你数据源不可用。3.3 用本地 HTTP 服务托管而不是双击打开文件很多新手会直接双击这个 HTML 文件然后发现页面里显示不了数据。原因是浏览器安全策略通常会限制file://协议下的本地文件读取尤其是fetch请求data.json时。所以你需要一个极轻量的 HTTP 服务。最简单的方式之一是在这个目录下启动一个 Python HTTP 服务cd path/to/info-panel python3 -m http.server 8080然后浏览器访问http://localhost:8080/panel.html如果 8080 端口被占用换个端口即可。如果你用的是python而不是python3把命令里的python3换成python再试。这一步只是临时服务后面要长期使用再把它配置成开机自启也不迟。如果刷新页面后仍然显示“数据源不可用”不要急着改代码。第一步先看data.json是否存在第二步看它的内容是否是合法 JSON。多数小故障都出在这两层。3.4 开机自启和防休眠的处理面板在浏览器里跑通后你当然不希望每次开机都手动打开浏览器。常见做法是把副屏设备配置成开机后自动打开指定 URL并进入全屏模式。如果你用的是 Chromium 内核浏览器一般可以通过浏览器启动参数进入 kiosk 模式。不同系统、不同版本的浏览器参数有差异落地时需要按自己的环境查一下。如果不想折腾浏览器参数也可以在操作系统的“启动应用程序”或“登录后启动”里加上这条命令开机后自动打开网页。这里有一个更务实的建议第一周不要追求全自动。先保持手动打开页面确认自己真的会每天看这个面板然后再去优化开机自启和全屏显示。一次性引入太多自动化不等于体验更好只等于故障点更多。另外别忽略系统休眠问题。显示器长期不操作系统默认可能会关闭屏幕或让设备休眠。如果副屏是专门用来显示信息终端的需要把相关的休眠策略关掉或者至少把“合上盖子”这类动作的默认行为调成不睡眠。长期亮屏对 LCD 一般问题不大如果是 OLED 屏幕要留意烧屏风险可以考虑降低亮度或者隔一段时间切换一下布局。4. 进阶从网页面板到真正的数据接入4.1 数据接入的三种方式静态 HTML 面板跑通后下一步就是接入真实数据源。常见的有三种方式。第一种是静态生成。写一个脚本定时去各个数据源拉取内容统一写到data.json前端页面只负责读取。这是最稳、最容易排查的方式适合大多数个人场景。第二种是接口轮询。页面直接用 JavaScript 向某个后端接口请求数据然后重新渲染。适合实时性要求较高的场景但它引入了跨域、后端服务、接口稳定性等问题复杂度明显上升。第三种是推送或 WebSocket。数据变化时服务端主动把更新推给前端。这种方式适合秒级响应的异常监控场景但对个人副屏信息终端来说通常过度设计。我的建议非常简单先用静态生成。如果发现某个信息确实需要更高频次刷新再考虑局部改成接口轮询。WebSocket 放到最后。4.2 一个数据更新器的通用流程静态生成路线的核心是一个能生成data.json的脚本。下面是一段可运行的 Python 示例结构import json from pathlib import Path # 1. 在这里按你的数据源写获取逻辑 # 例如从本地命令、缓存数据库或公开接口拿到结果 todo [写周报, 提交代码, 预约牙医] rss [ {title: 示例标题一, link: https://example.com/1}, {title: 示例标题二, link: https://example.com/2}, ] panel_data { todo: todo, rss: rss, } # 2. 生成前端需要的 data.json output_path Path(__file__).parent / data.json output_path.write_text( json.dumps(panel_data, ensure_asciiFalse, indent2), encodingutf-8 ) print(data.json updated:, output_path)这个脚本本身不复杂。真正的复杂度在“获取逻辑”你要把 TODO 来源、RSS 地址、构建状态接口都接进来然后统一写成panel_data。关键是先手动跑一次确认data.json被正确更新再去配置定时任务。定时任务方面常见做法是 Linux 上用 cronWindows 上用任务计划程序macOS 上用 launchd。以 cron 为例可以这样写*/5 * * * * cd /path/to/info-panel /usr/bin/python3 update_data.py注意这里的路径和对python3的引用只是示例结构实际使用时要改成自己的绝对路径并且先手动执行一次确认在定时任务环境里也能正常运行。很多时候定时任务跑失败不是因为逻辑写错而是因为环境变量和手动执行时不一样。4.3 数据源注意隐私和权限边界数据接入越深你放进面板里的东西就越私密。待办、日历、邮箱摘要、服务器状态这些都算个人信息甚至是敏感信息。首先API 密钥和账号信息不要硬编码在脚本里。更合理的做法是从环境变量读取或者放到单独的配置文件里并且不要把配置文件提交到 Git。其次如果你的信息终端只是在家里或工位局域网里看就不要随意做端口映射更不要把没有认证的仪表盘暴露到公网。一旦面板能被外网访问它就不只是你的“信息终端”也是一个潜在的被扫描对象。我会把这个原则放得很高默认不要暴露到公网。如果确实需要远程查看优先考虑成熟的认证、HTTPS 和访问控制方案而不是为了一时方便把端口直接开出去。对个人信息终端来说少一个远程入口就少一个泄漏面。5. 没有第二块显示器旧手机、旧平板也能当副屏5.1 常见替代载体的优缺点不是每个人都有闲置显示器也不是每个人都愿意为了副屏专门买一块屏幕。其实副屏信息终端对硬件的要求很低你手头的旧设备往往就能胜任。载体优点缺点适合场景旧显示器 闲置主机/迷你主机屏幕大、寿命长、显示效果稳定占地方、功耗相对高桌上本来就有旧设备愿意长期使用旧手机现成设备、功耗低、有触摸屏屏幕小、分辨率高导致字号问题想先用最少的成本试一下旧平板屏幕适中、可触屏、重量轻系统更新慢、长期充电有电池风险希望兼顾显示和简单交互开发板/树莓派类设备功耗低、稳定、扩展性强设置门槛高、还要另配显示屏想长期做成固定终端设备这张表不涉及具体型号因为在这个场景里硬件本身不是核心信息密度和显示亮度才是。哪怕是一台很旧的安卓手机只要能稳定打开浏览器、连续供电就能跑起网页信息终端。有一点值得注意旧手机和平板长期插电使用电池可能膨胀。如果你打算长期当固定副屏可以考虑拆掉电池、用电源直接供电或者至少不要在无人看管时长时间充电。这个细节很容易被忽视但它直接影响安全。5.2 从显示到交互先别急着做交互信息终端的第一个阶段是纯展示。等你用上一两周发现某个操作确实很频繁再考虑加交互。比如平板副屏你可以做一个简单的视图切换按钮工作视图显示待办和构建状态休息视图显示时间和订阅内容。用网页实现起来也不复杂其实就是切换 CSS class。但交互会引入状态管理会让“看板”变成“应用”所以我建议第一版先忍一忍把所有精力放在数据稳定和显示清晰上。信息终端的核心价值在“看”不在“点”。如果有一天你发现自己要在副屏上完成大量点击操作那说明它已经被拉回了“第二块主屏”的老路。6. 最容易踩坑的五个地方与排查链路6.1 新手最容易踩的坑先说最常见的五个坑。第一数据源 把副屏变成信息终端：从第二块主屏到状态可见层
很多人的副屏最终都变成了两种东西一个是不会动的壁纸一个是永远乱糟糟的备用窗口区。我自己也经历过这个阶段。刚多出一块显示器时第一反应是“终于可以一边写代码一边看文档了”后来发现文档窗口总是被聊天窗口盖住聊天窗口又总被终端盖住副屏不但没有提高效率反而成了一个专门用来“找窗口”的地方。后来换了一个思路不再把副屏当作主屏的扩展而是把它变成一台信息终端。它不负责给你提供操作空间只负责把那些需要持续关注、但不需要频繁操作的信息稳定地摆在你余光范围里。这个转变听起来不大实际体验却差很多。副屏从“第二块主屏”变成“状态可见层”之后你才真正开始用它。1. 先想明白副屏的定位不是“第二块主屏”而是“状态可见层”1.1 你需要的不是更多窗口而是减少切换成本大多数人添第二块屏幕理由是“终于可以同时看更多东西了”。这句话对却不完整。同时看到更多东西提升的只是“看到”这个动作本身真正影响效率的是“切换注意力”的成本。在主屏上你写代码、写文档、回消息、查资料窗口本来就多。当你把这些窗口再分一块到副屏上视觉空间是变大了但窗口之间的布局管理、焦点切换、滚动定位也变多了。尤其当副屏上同时堆着聊天、文档、文件管理器三种窗口时你每次需要用其中一个都要先找它在哪里。找窗口这个动作就是被新增的副屏放大的隐性成本。副屏作为信息终端正好绕开这个问题。它不需要你频繁地往上面拖窗口也不需要你记住哪个窗口在哪个位置。它只做一件事把一组固定信息以固定布局显示在那里。你不需要操作它只需要在需要的时候扫一眼。所以这里要做一个明确的定位调整副屏不是“第二个工作台”而是“状态可见层”。工作台是拿来操作的状态可见层是拿来“看”的。你把它当工作台它就会变成另一个窗口堆叠区你把它当状态可见层它才会真正减少你操作系统的次数。1.2 副屏信息终端的核心判断标准扫一眼能否获得状态怎么判断一个副屏信息终端做得好不好不需要看界面细节也不需要用复杂指标衡量。我习惯用一个很简单的测试你正在主屏写东西突然想确认“现在几点了”“今天下午有没有会”“构建是不是红了”眼睛从主屏移到副屏整个过程不超过一秒你能不能得到答案。如果看完副屏你还需要读一遍标题、找一遍内容、或者想一下“这个颜色到底代表正常还是异常”那说明它还不是一个合格的信息终端。信息终端追求的不是信息量而是“状态可知性”。这句话要再强调一遍副屏信息终端追求的不是信息量是状态可知性。它和大屏数据可视化不一样。数据大屏可以铺满两百个指标因为它的使用场景是“有人站在那里认真看”但副屏在你余光里你只会给它不到一秒的注意力。信息一多、字号一小、布局一乱就等于没有这块副屏。一个可行的做法是把副屏内容控制在“一屏能扫完”的密度。宁可少放三张卡片也不要为了填满屏幕而塞入一堆你根本不会看的数据。状态可见的前提是内容简单到被眼睛自动略过时仍然能抓住异常。2. 从需求反推内容别把壁纸和监控面板混为一谈2.1 三类最适合放副屏的信息哪些信息真正值得放在副屏上不是所有信息都适合。我的经验是它们通常具备三个特征低频变化、常驻可见、扫读即得。第一类时间、日历、待办。这几乎是副屏信息终端最稳的起点。日期、星期、当前时间、今日待办都是你每天会反复确认的信息。它们变化频率低不依赖外部服务即使其他数据源全部失效这块副屏也仍然有用。第二类开发状态、构建结果、服务器监控。这种信息很适合放在副屏尤其是团队开发或自己维护服务的人。它们的特点不是“需要一直盯着”而是“一旦异常需要尽早看见”。一块副屏上只显示“最近一次构建是否成功”“当前服务的错误数是否超过阈值”比放一整排复杂图表更实用。这里的关键设计是异常提示要做重正常时用灰色或绿色异常时用红色边框或者直接增大对应卡片的存在感。第三类订阅更新、邮件摘要、RSS 标题。你可以把每天会刷的信息源收敛成一个列表只显示标题和来源不点开、不收藏扫一眼就知道今天有什么值得看。这类信息的难点不在展示而在过滤。订阅源如果不经过筛选副屏上就会变成信息流瞬间失去“状态可见”的意义。这三类信息有一个共同点你一天可能会看它们很多次但每次只是确认状态不会在副屏上完成复杂操作。这正是信息终端和“第二操作区”的边界。2.2 一个四步拆解法目标、信息、形态、载体如果你不确定到底该在副屏上放什么我建议用下面这个四步拆解法它基本可以复用到任何个人信息终端场景。第一步确定副屏的位置和注视距离。副屏是放在正对面、侧面、还是桌子远端决定了字号和内容密度。如果你坐在离副屏一米外普通网页字号根本看不清信息越多越没用。先定物理位置再谈信息布局。第二步确定信息优先级。拿一张纸记录自己一周里每天会反复主动查看哪些信息时间、日历、待办、天气、构建状态、服务器负载、邮箱、订阅更新。然后做一个筛选只保留“一天超过三次、每次低于三秒”的信息。那些偶尔才看一眼的内容不值得占用副屏上的固定位置。第三步确定数据来源。对筛选出的信息逐项问一个问题数据能不能自动获取自动获取的依赖是什么比如时间不需要数据源待办如果来自某个任务管理器就需要它提供接口或文件构建状态则需要接入 CI/CD 的查询接口。自动获取的信息源越多系统的故障点就越多所以在一开始最好只保留一到两个自动数据源。第四步确定刷新频率和异常提示。不是所有数据都值得每秒刷新。时钟按秒刷新就够了构建状态每分钟刷新一次订阅列表十分钟刷新一次待办甚至可以只在页面加载时读取一次。对于异常类信息要做视觉强调不要让它淹没在一堆普通文字里。这四个步骤的优先级很明确先解决位置和阅读效率再决定放什么内容最后才考虑技术实现。很多人做副屏信息终端一上来就研究技术选型结果忘了自己到底要拿它看什么。2.3 不适合放副屏的信息类型把副屏定位成信息终端后也要清楚它不适合放什么。需要大量输入和操作的界面比如聊天窗口、IDE、设计软件不适合放副屏。你放在副屏上的东西越需要操作就越容易把你拉回主屏的窗口管理逻辑里信息终端的设计就失效了。需要连续阅读的长文也不适合。副屏通常在侧面距离和角度都不适合长时间阅读它更适合展示“标题级”信息而不是替代主屏完成阅读任务。更重要的是能让你的注意力被“吸走”的内容比如社交信息流、短视频推荐、新闻瀑布流也不适合放副屏。信息终端和娱乐屏的差别在于前者是被动展示状态后者是主动消费内容。如果你发现自己在副屏前刷了三分钟那么这个副屏的定位已经偏了。3. 最小可用方案用一个网页把副屏变成信息终端3.1 为什么先用网页方案而不是装一堆桌面小组件想清楚放什么内容之后接下来才是技术方案。我不建议一开始就装一堆桌面小组件也不建议直接上重型自托管监控平台。那个思路听起来很酷但维护成本会迅速超过收益。一个更稳的切入点是用网页。网页方案的好处是跨平台、好调试、可复用。你在一台正常显示器上把 HTML 页面调好然后同样的页面可以跑在旧手机、旧平板、树莓派或者任何带浏览器的设备上。改样式只需要改 HTML 和 CSS刷新浏览器就能看到效果不需要重新打包、重新安装。而且网页方案可以从一个非常小的闭环开始一个 HTML 页面一个 JSON 数据文件一个本地 HTTP 服务。先跑通“显示数据”这条链路再逐步增加数据源。这个路径足够简单也足够稳。3.2 用一个 HTML 面板把数据展示出来这里给一个最小可用的示例。它不依赖任何外部接口只是从同一个目录下的data.json读取数据然后渲染到页面上。这样你可以先把“数据文件 → 页面展示”的链路跑通后续再替换真实数据源。data.json可以先用这样一份结构{ todo: [写周报, 提交代码, 预约牙医], rss: [ { title: 示例标题一, link: https://example.com/1 }, { title: 示例标题二, link: https://example.com/2 } ] }面板页面的核心结构大致如下!DOCTYPE html html langzh-CN head meta charsetUTF-8 titleDesk Info Panel/title style :root { --bg: #111; --card: #1c1c1c; --text: #eee; --muted: #888; } * { box-sizing: border-box; margin: 0; padding: 0; } body { background: var(--bg); color: var(--text); font-family: system-ui, sans-serif; } .grid { display: grid; grid-template-columns: repeat(2, 1fr); gap: 16px; padding: 20px; height: 100vh; } .card { background: var(--card); border-radius: 12px; padding: 20px; overflow: hidden; } .clock { font-size: 64px; font-weight: 700; } .date { font-size: 28px; color: var(--muted); } .card h3 { font-size: 18px; color: var(--muted); margin-bottom: 8px; } ul { list-style: none; } li { padding: 6px 0; border-bottom: 1px solid #2a2a2a; font-size: 16px; } .error { color: #ff6b6b; font-size: 14px; } /style /head body main classgrid section classcard div classclock idclock--:--:--/div div classdate iddate----/div /section section classcard h3今日待办/h3 ul idtodo-list/ul /section section classcard h3订阅/h3 ul idrss-list/ul /section section classcard h3运行状态/h3 p iddata-status等待数据源.../p /section /main script function escapeHtml(str) { return String(str).replace(/[]/g, function (c) { return { : amp;, : lt;, : gt;, : quot;, : #39; }[c]; }); } function refreshTime() { const now new Date(); document.getElementById(clock).textContent now.toLocaleTimeString(zh-CN, { hour12: false }); document.getElementById(date).textContent now.toLocaleDateString(zh-CN, { year: numeric, month: long, day: numeric, weekday: long }); } async function refreshData() { try { const res await fetch(./data.json, { cache: no-store }); if (!res.ok) throw new Error(HTTP res.status); const data await res.json(); const todoHtml (data.todo || []) .map(item li${escapeHtml(item)}/li) .join(); document.getElementById(todo-list).innerHTML todoHtml; const rssHtml (data.rss || []) .map(item lia href${escapeHtml(item.link)} target_blank${escapeHtml(item.title)}/a/li ) .join(); document.getElementById(rss-list).innerHTML rssHtml; document.getElementById(data-status).textContent 数据源正常; } catch (err) { document.getElementById(data-status).textContent 数据源不可用 err.message; } } refreshTime(); setInterval(refreshTime, 1000); refreshData(); setInterval(refreshData, 30000); /script /body /html这个面板做了几件事显示时钟和日期读取同级目录的data.json把待办和订阅列表渲染出来数据源出错时在“运行状态”卡片里给出提示。它不算漂亮但足够稳定而且可以继续演化。这里有一个关键设计就是把“获取数据”和“展示数据”分开。数据更新逻辑不放在页面里而是由外部脚本生成data.json。页面只负责读取文件、渲染结果。这样数据源挂了页面不会白屏而是明确告诉你数据源不可用。3.3 用本地 HTTP 服务托管而不是双击打开文件很多新手会直接双击这个 HTML 文件然后发现页面里显示不了数据。原因是浏览器安全策略通常会限制file://协议下的本地文件读取尤其是fetch请求data.json时。所以你需要一个极轻量的 HTTP 服务。最简单的方式之一是在这个目录下启动一个 Python HTTP 服务cd path/to/info-panel python3 -m http.server 8080然后浏览器访问http://localhost:8080/panel.html如果 8080 端口被占用换个端口即可。如果你用的是python而不是python3把命令里的python3换成python再试。这一步只是临时服务后面要长期使用再把它配置成开机自启也不迟。如果刷新页面后仍然显示“数据源不可用”不要急着改代码。第一步先看data.json是否存在第二步看它的内容是否是合法 JSON。多数小故障都出在这两层。3.4 开机自启和防休眠的处理面板在浏览器里跑通后你当然不希望每次开机都手动打开浏览器。常见做法是把副屏设备配置成开机后自动打开指定 URL并进入全屏模式。如果你用的是 Chromium 内核浏览器一般可以通过浏览器启动参数进入 kiosk 模式。不同系统、不同版本的浏览器参数有差异落地时需要按自己的环境查一下。如果不想折腾浏览器参数也可以在操作系统的“启动应用程序”或“登录后启动”里加上这条命令开机后自动打开网页。这里有一个更务实的建议第一周不要追求全自动。先保持手动打开页面确认自己真的会每天看这个面板然后再去优化开机自启和全屏显示。一次性引入太多自动化不等于体验更好只等于故障点更多。另外别忽略系统休眠问题。显示器长期不操作系统默认可能会关闭屏幕或让设备休眠。如果副屏是专门用来显示信息终端的需要把相关的休眠策略关掉或者至少把“合上盖子”这类动作的默认行为调成不睡眠。长期亮屏对 LCD 一般问题不大如果是 OLED 屏幕要留意烧屏风险可以考虑降低亮度或者隔一段时间切换一下布局。4. 进阶从网页面板到真正的数据接入4.1 数据接入的三种方式静态 HTML 面板跑通后下一步就是接入真实数据源。常见的有三种方式。第一种是静态生成。写一个脚本定时去各个数据源拉取内容统一写到data.json前端页面只负责读取。这是最稳、最容易排查的方式适合大多数个人场景。第二种是接口轮询。页面直接用 JavaScript 向某个后端接口请求数据然后重新渲染。适合实时性要求较高的场景但它引入了跨域、后端服务、接口稳定性等问题复杂度明显上升。第三种是推送或 WebSocket。数据变化时服务端主动把更新推给前端。这种方式适合秒级响应的异常监控场景但对个人副屏信息终端来说通常过度设计。我的建议非常简单先用静态生成。如果发现某个信息确实需要更高频次刷新再考虑局部改成接口轮询。WebSocket 放到最后。4.2 一个数据更新器的通用流程静态生成路线的核心是一个能生成data.json的脚本。下面是一段可运行的 Python 示例结构import json from pathlib import Path # 1. 在这里按你的数据源写获取逻辑 # 例如从本地命令、缓存数据库或公开接口拿到结果 todo [写周报, 提交代码, 预约牙医] rss [ {title: 示例标题一, link: https://example.com/1}, {title: 示例标题二, link: https://example.com/2}, ] panel_data { todo: todo, rss: rss, } # 2. 生成前端需要的 data.json output_path Path(__file__).parent / data.json output_path.write_text( json.dumps(panel_data, ensure_asciiFalse, indent2), encodingutf-8 ) print(data.json updated:, output_path)这个脚本本身不复杂。真正的复杂度在“获取逻辑”你要把 TODO 来源、RSS 地址、构建状态接口都接进来然后统一写成panel_data。关键是先手动跑一次确认data.json被正确更新再去配置定时任务。定时任务方面常见做法是 Linux 上用 cronWindows 上用任务计划程序macOS 上用 launchd。以 cron 为例可以这样写*/5 * * * * cd /path/to/info-panel /usr/bin/python3 update_data.py注意这里的路径和对python3的引用只是示例结构实际使用时要改成自己的绝对路径并且先手动执行一次确认在定时任务环境里也能正常运行。很多时候定时任务跑失败不是因为逻辑写错而是因为环境变量和手动执行时不一样。4.3 数据源注意隐私和权限边界数据接入越深你放进面板里的东西就越私密。待办、日历、邮箱摘要、服务器状态这些都算个人信息甚至是敏感信息。首先API 密钥和账号信息不要硬编码在脚本里。更合理的做法是从环境变量读取或者放到单独的配置文件里并且不要把配置文件提交到 Git。其次如果你的信息终端只是在家里或工位局域网里看就不要随意做端口映射更不要把没有认证的仪表盘暴露到公网。一旦面板能被外网访问它就不只是你的“信息终端”也是一个潜在的被扫描对象。我会把这个原则放得很高默认不要暴露到公网。如果确实需要远程查看优先考虑成熟的认证、HTTPS 和访问控制方案而不是为了一时方便把端口直接开出去。对个人信息终端来说少一个远程入口就少一个泄漏面。5. 没有第二块显示器旧手机、旧平板也能当副屏5.1 常见替代载体的优缺点不是每个人都有闲置显示器也不是每个人都愿意为了副屏专门买一块屏幕。其实副屏信息终端对硬件的要求很低你手头的旧设备往往就能胜任。载体优点缺点适合场景旧显示器 闲置主机/迷你主机屏幕大、寿命长、显示效果稳定占地方、功耗相对高桌上本来就有旧设备愿意长期使用旧手机现成设备、功耗低、有触摸屏屏幕小、分辨率高导致字号问题想先用最少的成本试一下旧平板屏幕适中、可触屏、重量轻系统更新慢、长期充电有电池风险希望兼顾显示和简单交互开发板/树莓派类设备功耗低、稳定、扩展性强设置门槛高、还要另配显示屏想长期做成固定终端设备这张表不涉及具体型号因为在这个场景里硬件本身不是核心信息密度和显示亮度才是。哪怕是一台很旧的安卓手机只要能稳定打开浏览器、连续供电就能跑起网页信息终端。有一点值得注意旧手机和平板长期插电使用电池可能膨胀。如果你打算长期当固定副屏可以考虑拆掉电池、用电源直接供电或者至少不要在无人看管时长时间充电。这个细节很容易被忽视但它直接影响安全。5.2 从显示到交互先别急着做交互信息终端的第一个阶段是纯展示。等你用上一两周发现某个操作确实很频繁再考虑加交互。比如平板副屏你可以做一个简单的视图切换按钮工作视图显示待办和构建状态休息视图显示时间和订阅内容。用网页实现起来也不复杂其实就是切换 CSS class。但交互会引入状态管理会让“看板”变成“应用”所以我建议第一版先忍一忍把所有精力放在数据稳定和显示清晰上。信息终端的核心价值在“看”不在“点”。如果有一天你发现自己要在副屏上完成大量点击操作那说明它已经被拉回了“第二块主屏”的老路。6. 最容易踩坑的五个地方与排查链路6.1 新手最容易踩的坑先说最常见的五个坑。第一数据源