CSS on 小景

苹果风格网页时钟小组件：上线心得与技术细节

Fri, 24 Jul 2026 20:00:00 +0200

本文介绍博客主页新上线的苹果风格双时区网页时钟小组件，并分享它背后的设计取舍、时区计算和模拟表盘实现。

现在打开桌面版博客主页，可以在搜索框下面看到两个模拟时钟：左边是访客的“你的时间”，右边是站长的“我的时间”。界面没有“世界时钟”标题，也没有显示我的姓名或所在国家。

它看起来只是主页上的一个小装饰，真正动手之后却碰到了不少值得讨论的问题：浏览器怎样处理时区和夏令时、模拟指针如何计算角度、网站主题与表盘昼夜如何分离，以及一个实时变化的视觉组件怎样兼顾双语和无障碍体验。

可复用的源代码已经发布到 GitHub： Jingyuan-Zheng/apple-style-web-clock-widget。仓库采用 MIT 许可证，包含可独立运行的演示、零框架 CSS 与 JavaScript、中英文说明、配置示例，以及时区和指针角度测试。

为什么选择苹果风格

这个组件的视觉语言明显受到苹果时钟界面的启发：圆形表盘、纤细指针、克制的数字、醒目的橙色秒针，以及带有柔和层次的圆角卡片。

我并不想逐像素复制某一个苹果应用，而是希望保留它最值得借鉴的部分：

不看文字也能立刻认出这是时钟；
两个时区属于同一组信息，但又能快速区分；
文字只负责解释必要信息；
阴影和材质服务于层次，而不是抢走表盘的注意力。

所以最后留下的可见文字只有 “你的时间” 和 “我的时间”。“世界时钟”这个标题其实没有增加新信息，姓名和国家也不是完成时间比较所必需的内容。删掉它们以后，组件反而更像一个安静地融入主页的系统小部件。

同一个此刻，两种墙上时间

时区功能最重要的原则，是两个表盘必须来自同一个瞬间，而不是各自独立计时。

每次刷新都先创建同一个 Date：

`1`	`const now = new Date();`

访客时区由浏览器提供：

1
2

const localZone =
    Intl.DateTimeFormat().resolvedOptions().timeZone || "UTC";

另一个表盘读取网站预设的 IANA 时区。两者都交给 Intl.DateTimeFormat，再通过 formatToParts() 拆出年、月、日、时、分、秒。

这里没有简单地给当前时间“加几个小时”。固定写死 +1 或 +2 看似方便，一旦遇到夏令时切换就会出错。让浏览器根据 IANA 时区和当前日期计算，才能在不同季节得到正确结果。

怎样计算时差

显示两个时间并不难，真正容易出错的是下面那行“相差几小时”。

组件会把目标时区格式化后的年月日时分秒，暂时当作 UTC 时间重新组合：

const wallTimeAsUtc = Date.UTC(
    year,
    month - 1,
    day,
    hour,
    minute,
    second,
);

const offsetMinutes =
    Math.round((wallTimeAsUtc - currentSecond) / 60000);

得到目标时区相对 UTC 的分钟偏移后，再减去访客本地的偏移量：

`1`	`targetOffsetMinutes - localOffsetMinutes`

我保留了小数时差的格式化，因为真实世界并不是所有时区都相差整数小时。有些地区相差半小时，甚至四十五分钟。一个世界时钟如果默认全世界都按整点划分，看起来简洁，实际并不可靠。

模拟指针其实是一道几何题

一圈是 360 度，因此每分钟和每秒对应 6 度，每小时对应 30 度：

1
2
3

const minuteAngle = minute * 6;
const hourAngle = (hour % 12) * 30 + minuteAngle / 12;
const secondAngle = second * 6;

时针公式里的 minuteAngle / 12 很重要。没有它，时针只会在整点突然跳到下一个数字；加上分钟带来的偏移后，时针才会随着时间平滑地走过两个小时刻度之间的位置。

每根指针本质上都是一个绝对定位的细长元素，旋转中心放在底部中央：

1
2

transform: rotate(var(--clock-rotation));
transform-origin: bottom center;

JavaScript 只更新角度变量，指针的长度、粗细、颜色和位置都留给 CSS。这样比每秒拼接一大段行内样式更清楚，也让视觉调整不必改动计时逻辑。

十二个数字则由 Hugo 模板循环生成。CSS 先把每个数字容器旋转到对应位置，再对子元素做反向旋转，让数字沿圆周排列却始终保持正立。

网站深浅色和表盘昼夜不是一回事

这个组件其实有两套互不相同的颜色逻辑。

外层卡片跟随博客的亮色或暗色主题，让它在右侧栏里看起来属于同一个网站；表盘本身则根据各自显示的时间判断白天和夜晚：

07:00–18:59 使用浅色表盘；
19:00–06:59 使用深色表盘。

这个区分是后来特别调整的。如果表盘也只跟随网站主题，那么用户把博客切到暗色模式后，即使某个时区正值白天，表盘也会变黑，原本有意义的昼夜提示就消失了。

现在两个表盘会分别检查自己的当地小时，因此一个浅色、一个深色是完全正常的状态，也正是世界时钟最直观的价值之一。

每秒重算，而不是自己数秒

组件使用 setInterval 每秒刷新一次，但它不会在上一次结果上简单加一秒。

每次触发都会重新读取当前 Date，再计算两个时区、时差和全部指针角度。浏览器把后台标签页的定时器暂停或延迟后，下一次刷新仍会直接回到正确时间，不会把延迟逐渐累积成走时误差。

同样的思路也能自然处理系统时间变化和夏令时切换。这里的定时器只是提醒界面重新绘制，真正的时间来源始终是系统时钟。

在 Hugo 里怎样接入

我把时钟写成一个独立的 Hugo partial，并在主页 widget 配置中把它放到搜索框之后。这样没有修改搜索组件本身，以后想调整顺序或移除时钟，只需要改 widget 列表。

整个实现分成三层：

Hugo 模板负责结构、十二个数字和中英文标签；
SCSS负责卡片、表盘、指针、阴影以及明暗状态；
TypeScript负责时区解析、时差计算和每秒更新。

GitHub 开源版本去掉了 Hugo 依赖，并把相同思路整理成标准 data-* 属性。普通网页无需框架或构建工具，也可以直接嵌入和配置。

组件只出现在宽度不小于 1024 像素的桌面右侧栏，手机端不会显示，也不会占据正文空间。这不是“移动版还没做完”，而是有意的取舍。手机屏幕有限，导航和文章内容的优先级明显高于一个辅助性的时间对比。

双语和无障碍不能最后再补

会动的指针对屏幕阅读器没有意义，因此每个表盘都会获得一段实时更新的无障碍说明，包含表盘名称、数字时间和时差。页面上已经可见的时差文字则对屏幕阅读器隐藏，避免同一信息被重复朗读。

文字由当前 Hugo 语言决定：

英文使用 “Your time”“My time”“hour / hours”；
简体中文使用“你的时间”“我的时间”“小时”。

内部解析固定使用公历和拉丁数字，避免计算逻辑受浏览器显示语言影响；真正呈现给读者的标签再根据页面语言本地化。把计算格式和展示语言分开，双语实现会稳定很多。

这个小组件带来的心得

做完以后，我最大的感受是：小组件最需要的不是更多功能，而是更清楚的边界。

我先后去掉了组件标题、姓名、国家和移动端版本；又把网站主题与表盘昼夜拆成两套逻辑。时区规则交给浏览器，表盘绘制则尽量留在简单的 CSS 和几何计算里。

最后它只做一件事：用两个时钟完成一次时间比较。没有设置面板，没有城市列表，也没有复杂交互。正是这种克制，让它更像主页的一部分，而不是一个在侧边栏里争夺注意力的迷你应用。

越小的界面，设计和工程之间的距离往往越近。多一行文字、多一个颜色条件、多一个断点，都会立刻改变视觉结果。这次上线也提醒了我：所谓精致，很多时候并不是不断添加，而是认真决定哪些东西可以不出现。

Safari 中文字体变宋体、显示不统一混用不同字体？完整修复方法，CSS恢复默认苹方黑体

Wed, 22 Jul 2026 11:00:00 +0200

本文介绍一个面向 macOS Safari 的中文字体修复方案：下载一个 CSS 文件并在 Safari 中选中它，就能让意外变成宋体的中文恢复为苹方。

如果你遇到的是下面这种情况，这个方案通常正好适用：

同一个网页里，大部分中文正常，部分按钮、导航或正文却突然变成宋体；
Chrome 中显示正常，Safari 中却不一致；
英文和数字没有问题，只有中文字体看起来很突兀。

这通常不是乱码，也不用重装字体或 Safari。可以先直接按下面的方法修复，技术原因放在后面解释。

先把问题解决

我为这个问题整理了一个开源方案：Safari CJK Font Fallback Fix。它只有一个 CSS 文件，不需要安装字体或 Safari 扩展。

下载项目中的 safari-fix.css。
打开 Safari，进入“Safari 浏览器 → 设置 → 高级”。
在“样式表”菜单中选择刚刚下载的 safari-fix.css。
使用 Command+Q 完整退出 Safari，然后重新打开。

图 1：在 Safari“设置 → 高级 → 样式表”中选择 safari-fix.css。

只刷新网页可能不会生效，一定要完整退出并重新打开 Safari。以后如果想停用，回到同一个菜单改为“未选择”即可。

项目地址：Jingyuan-Zheng/Safari-CJK-Font-Fallback-Fix。如果它解决了你的问题，也欢迎在 GitHub 上点一个 Star，让更多遇到同样问题的人更容易发现它。

修复前后有什么区别

下面是同一个 B 站页面的实际对比。图 2 是正常的苹方效果，图 3 则是 Safari 意外显示宋体时的效果。

图 2：正常效果，页面中的中文使用苹方。

图 3：异常效果，同一页面中的部分中文变成宋体。

为什么这个方案比网上的常见办法更好

网上常见的做法，是强制所有网页、所有文字都使用苹方。这样确实简单，但更像是把整个网站的排版重新刷了一遍。

它可能带来新的问题：

网页图标变成方块；
代码块失去原来的等宽字体；
英文标题和数字也被一并改掉；
网站本来有意使用的宋体、楷体或仿宋被错误替换。

这个项目采用的是更克制的方式：只补上缺失的中文字体，不接管整个网页的设计。

因此，启用后：

意外变成宋体的中文会优先恢复为苹方；
英文、数字、图标和代码字体继续使用网站原来的设置；
网站明确选择的宋体、楷体和仿宋仍然保留；
普通文字和粗体会使用对应的苹方字重；
一个文件即可作用于 Safari，不必为每个网站分别安装脚本。

它修复的是“意外回退”，而不是把所有网页强行统一成一种字体。

为什么 Safari 会突然选到宋体

很多网页首先指定 Arial、Helvetica、Inter 或 Roboto 等西文字体。这些字体能显示英文和数字，却不一定包含中文。Safari 遇到汉字时，只能继续寻找另一种可用字体，有时最终就选到了宋体。

这就是所谓的“字体回退”：首选字体没有某个字符时，浏览器自动换用另一种字体来显示。不同浏览器的选择结果可能不同，所以同一个页面才会出现 Chrome 正常、Safari 却变成宋体的情况。

这个项目做的事情，可以简单理解为：当常见西文字体缺少中文时，告诉 Safari 优先用 macOS 自带的苹方补上；英文和网页原有的其他字体不动。

如果你对实现细节感兴趣，下面是最核心的一小段。它表达的意思是：当 Arial 缺少中文字符时，只用苹方补上指定的中文范围。

@font-face {
    font-family: "Arial";
    src: local("PingFangSC-Regular");
    unicode-range: U+3000-303F, U+3400-4DBF,
        U+4E00-9FFF, U+F900-FAFF, U+FF00-FFEF;
}

实际文件还包含粗体、繁体中文、扩展汉字，以及 Helvetica、Roboto、Inter、微软雅黑等常见字体名称的完整规则。不要只复制上面的示例片段，直接下载项目维护的完整 safari-fix.css 即可。

隐私与适用范围

项目只有 CSS，不含 JavaScript，不读取浏览记录、账号或网页内容，不包含统计与遥测，也不会发起网络请求。

它面向 macOS 上的 Safari。网页内嵌区域、特殊组件以及图片中的文字可能不受影响；如果网站刻意采用“英文无衬线、中文宋体”的设计，样式表也不一定能百分之百判断设计者的意图。

常见问题

为什么导入后没有立即生效？

请使用 Command+Q 完整退出 Safari，再重新打开。普通刷新通常不会重新读取用户样式表。

它会把所有宋体都换成苹方吗？

不会。项目保留了明确指定的宋体、楷体和仿宋，只处理本应采用无衬线字体却发生错误回退的情况。

会影响英文 Arial 或 Helvetica 吗？

不会。样式表只为中文字符补充苹方，英文字母、数字、字宽和间距仍由原字体处理。

需要安装字体或 Safari 扩展吗？

不需要。苹方是 macOS 的系统中文字体，Safari 本身支持加载用户样式表。

一个小问题，也值得被认真修好

字体回退很少让网页彻底不能用，但它会不断制造细小的视觉跳变。尤其在一整页干净的苹方中突然出现一行宋体时，你很难再假装没有看见。

这个项目不试图替网站决定所有排版，只在浏览器缺少合适的中文无衬线字形时，补上更符合 macOS 阅读体验的那一块。一个 CSS 文件，随时启用、随时关闭，也不要求把浏览权限交给扩展。

如果你遇到新的 Safari 中文字体回退问题，可以在 GitHub Issues 提交公开复现网址、实际 font-family、macOS 与 Safari 版本，以及预期和实际字体。请不要附上私人网址、账号信息或浏览记录。