浏览器收藏夹能保存链接，却很难回答今天先看什么。项目更新在 GitHub，文章在订阅阅读器，服务器状态在另一个面板，常用工具又散在书签目录。打开一个新标签页后，往往先花时间寻找入口。
Glance 可以把部分订阅、书签与状态放到一个页面里，配置保存在 YAML 文件中。它适合做信息入口，前提是愿意删掉不常用的内容。页面放得越多，维护和分心的成本越高；日常首页最有价值的地方，是让经常发生的几种操作变得顺手。
用一天的实际操作决定页面内容
先写下自己每天会打开的几个地方：站点管理、订阅阅读、项目发布记录、笔记、备份控制台。然后决定首页要显示信息还是只提供入口。
需要知道“有没有更新”的项目，可以显示少量 RSS 条目；需要连续阅读和标记已读的订阅，仍交给 FreshRSS 等阅读器；管理页面放成书签；服务状态则只显示少数关键入口。这样首页不会承担所有工具的工作，也不必把上百个订阅搬进同一列。
可以先做“今日”和“管理”两页。今日页放阅读与经常使用的工具，管理页放站点、代码仓库和状态。新增模块前，观察自己是否真的使用它。如果每次都忽略一个区域，删除比调整配色更有帮助。
本机试运行，再决定是否使用域名
Glance 项目提供 Docker 示例。以下配置把服务限制在本机，适合先通过 SSH 转发使用。示例使用默认镜像标签，正式运行前应选择并固定核实过的版本或摘要。
services:
glance:
image: glanceapp/glance
ports:
- "127.0.0.1:8080:8080"
volumes:
- ./config:/app/config
restart: unless-stopped
在同一目录创建 config/glance.yml：
pages:
- name: 今日
columns:
- size: small
widgets:
- type: bookmarks
groups:
- title: 常用入口
links:
- title: 订阅阅读
url: https://reader.example.com
- title: 笔记
url: https://notes.example.com
- size: full
widgets:
- type: rss
title: 项目动态
limit: 8
collapse-after: 4
cache: 2h
feeds:
- url: https://github.com/glanceapp/glance/releases.atom
title: Glance 发布
example.com 地址是占位示例，需要替换成自己的服务。RSS 使用公开项目的发布订阅作为可用示例，后面可以换成自己关注的博客或项目。
docker compose config --quiet
docker compose up -d
docker compose logs --tail=80 glance
ssh -L 18080:127.0.0.1:8080 user@your-server
打开本机 http://127.0.0.1:18080。Compose 配置校验只检查容器编排，Glance 自身的 YAML 是否正确还要看应用日志和页面。缩进错误、字段放错层级、复制来的地址失效，都是起步阶段常见问题。
开始只放少量模块，能更容易判断错误来自配置还是数据源。不要从一个复杂示例复制几十个 widget，然后试着同时排查。
把阅读区做得短一点
首页阅读区显示的是近期线索，不是所有内容。八条更新、默认展开四条，可以在页面首屏留下空间；频繁发文的站点占满列表时，考虑拆分来源或减少条数。新闻聚合与项目发布最好分开，避免高频内容挤掉低频但有用的版本更新。
订阅缓存间隔取决于用途。个人博客两小时缓存往往已经足够；项目发布记录也不必几十秒抓取。间隔缩得很短，不等于能保证实时收到更新，还可能让远端限流。配置中的 cache 控制数据刷新，读者仍需要理解页面显示的是最近一次成功获得的数据。
RSS 内容缺失时，先直接访问订阅地址，确认它确实返回 feed，而不是网站 HTML 或登录页面。接着检查服务器访问、证书和应用日志。浏览器能访问不代表容器所在网络路径也正常。
有些站点只提供摘要，这是源站的内容安排，不是面板出错。需要全文和历史阅读记录时，点击进入原文或阅读器。不要为了“首页内容完整”抓取大量全文，让一个入口页变得缓慢又难浏览。
服务状态只做入口级判断
可以在管理页加一个简单的监控模块：
pages:
- name: 管理
columns:
- size: full
widgets:
- type: monitor
title: 服务入口
cache: 1m
sites:
- title: 主站
url: https://www.example.com
- title: 阅读器
url: https://reader.example.com
这段应作为现有 pages 数组中的第二项加入，不能在文件里建立两个重复的顶层 pages。监控模块依据请求响应判断入口状态，默认行为及可配置选项见 Glance 配置说明。
返回正常状态码只能说明一次请求满足检查条件。数据库连接、用户登录、上传和后台任务是否正常，需要更具体的业务检查。首页绿色图标不能替代正式告警系统，更不能证明备份可恢复。
还有一个容易混淆的地址问题：Glance 容器里请求 127.0.0.1，访问的是容器自己，不是宿主机，也不是用户电脑。如果要检查同一 Compose 网络中的服务，应使用对应服务名与内部端口；供浏览器点击的链接，则要使用浏览器能够访问的域名。内部检查地址和外部打开地址可能不同，按模块文档配置。
认证页面返回 401 或跳转也可能影响结果。先弄清检查目标：要判断反向代理是否在线，还是要验证内部服务。不要把登录限制移除，只为了让状态变绿。
公开访问前，先保护私人信息
只有自己通过 SSH 隧道使用时，不需要急着配置公开域名。打算开放访问时，应加 HTTPS 和适合的身份验证。面板里的内网服务名、管理地址、私人订阅和 API 数据，都可能透露不希望公开的信息。
Glance 提供内置认证。先生成会话密钥：
docker run --rm glanceapp/glance secret:make
使用官方 password:hash 命令生成密码哈希，再写入配置的 password-hash 字段。不要把真实密码留在共享命令记录、截图或 shell 历史中；按自己的终端管理方式避免记录，生成后保存哈希即可。
auth:
secret-key: ${GLANCE_SECRET_KEY}
users:
owner:
password-hash: ${GLANCE_PASSWORD_HASH}
配置支持环境变量替换，但宿主机 .env 中写了变量，不代表变量已经进入容器。Compose 里还要明确传入：
environment:
GLANCE_SECRET_KEY: ${GLANCE_SECRET_KEY:?set session key}
GLANCE_PASSWORD_HASH: ${GLANCE_PASSWORD_HASH:?set password hash}
这段添加到 Glance 服务配置中。应用环境变化需要重新创建相应容器，不能期待修改宿主机文件后正在运行的进程自动获得新变量。密钥和哈希都保存到受限配置中，公开仓库只留下占位说明。
保护页面不等于保护配置。若给某个 widget 配置 API 令牌，仍应按最小范围授权，避免为了读取少量数据使用管理员凭据。一个只有阅读功能的首页也不需要挂载 Docker socket；想显示容器信息时，应先评估这个功能需要哪些访问权限。
文件修改后，确认真正生效的是哪份配置
Glance 支持配置重载，但环境变量变化与普通 YAML 变化不同。修改后看日志、刷新页面，再确认实际显示。运行中的无效配置可能未被采用，旧页面仍能显示，并不能证明新文件正确。
配置放进 Git 能记录调整过程，但只提交不含凭据的部分。将首页的布局、订阅列表和入口与秘密分开，比较容易审阅。每次调整只改一类东西，例如先换 feed，再改列布局，出了问题也更容易回到上一版。
重载和重启可能导致缓存重新获取，一次添加很多远端模块时应留意访问频率。缓存时间和服务器资源不是唯一影响，远端 API 的额度也要考虑。
手机上尤其容易看出布局问题。实际打开窄屏页面，确认书签不难点、标题不挤成几行、首屏没有被一长串订阅占满。桌面上三列看起来整齐，手机上仍可能需要大量滚动。内容顺序应按照使用频率，而不是按照组件种类排列。
配置越多，越需要一个取舍标准
可以把一周内的使用分成三种：每天点击的入口，偶尔浏览的信息，几乎从未看过的模块。第一种保留在醒目位置，第二种放到独立页面或折叠区域，第三种直接删掉。这个方法不需要记录详细的私人浏览数据，凭实际使用回顾也能做。
对多站点维护者，管理页可以按站点分组，让网站首页、后台和文档入口放在一起。后台链接应指向已有安全入口，不需要把登录令牌拼进 URL。书签能帮你更快找到后台，不能替代后台本身的身份验证。
家人共同使用的面板与个人管理页，也应该分开。家庭页放天气、常用服务和双方认可的订阅；服务器管理与私人项目留在自己受保护的实例或入口。不要因“大家都在家里”就把所有模块放到一个可分享的页面。
若一个模块经常超时，暂时移除它，检查剩余页面是否恢复。再单独验证数据源和网络路径，可以减少把整页缓慢归因于服务器规格的误判。对于低价值来源，与其花几小时调整代理，不如保留链接让需要时再访问。
调整缓存时也要有目的。服务入口需要较短间隔，阅读条目可以长一些，静态书签则不涉及远端数据更新。所有模块统一设成十秒，并不会让首页更可靠，只会让远端请求和资源消耗增加。
备份首页配置，也备份它的使用条件
Glance 的主要维护资产是配置和相关秘密。保留 compose.yaml、去除秘密后的 YAML、当前镜像标识，并在受控位置备份会话密钥和令牌。只保留截图，无法恢复数据源和认证设置。
恢复时先在本地或隧道下启动，确认订阅、链接与认证正常，再接公开域名。一个旧书签指向已经停用的管理入口，通常不会报错提醒你，所以恢复验收也要逐个打开关键链接。
首页运行一两周后，检查哪些模块确实被使用。删掉没有帮助的排行榜、重复订阅和失效入口，保留日常操作最常见的几个。Glance 的配置很灵活，但对个人首页而言，克制地选择信息比增加组件更能让它长期留下来。