普通视图

过去的互联网完全由网站组成

2025年8月29日 23:08

过去的互联网完全由网站组成 - 第1张图片

Younger readers may not even know that the internet used to be made entirely of websites, created by human beings, connected only by hyperlinks.

年轻的读者可能甚至不知道,互联网曾经完全由网站组成,这些网站是由人类创建的,仅通过超链接连接。

上面这段话来自 Raptitude 的文章《How to Surf the Web in 2025, and Why You Should》,听起来匪夷所思,2025 年了,上网还需要人教吗?一部手机应该就足够了吧,但实际情况是会用手机不一定会上网,手机上的应用软件像是打包好了的各种各样的内容,只需要你点开它,肆意滑动屏幕,上下或者左右即可。然而,互联网过去完全由网站组成。

作者在文章中提到,要冲浪,就需要从一个带有外部链接的普通网站开始,同时也要避免所有由算法驱动的网站,例如 Twitter、Reddit、微博,包括上面提到的应用软件,尽快大部分互联网的流量都流向了他们,最后你必须使用真正的电脑,而不是手机,使用社交媒体不算是上网冲浪。

这让我回忆起 15 年前第一次上网的场景,通过 hao123 网站,进入了 43997k7k 小游戏网站,我依然记得当时的 hao123 上面有各种类型的链接,按照不同的分类进行摆放,非常直观地让你一眼看到并进入想要浏览的网站。令人泪目的是,时至今日访问 4399,页面和 15 年前几乎没什么区别。

最直观的显示外部链接的方式,我觉得就是文字下方画一条横线,并显示为蓝色,这已经是刻在 DNA 里的印象,一看到类似的文字就忍不住点开,跳转到另一个网站探寻新的内容。学会用 Google 之后偶然间发现了 Wikipedia,任意进入一个词条页面,都有许多蓝色字体链接着另一个词条,而站外链接则是用参考文献的方式放在了最末尾,没有下划线,似乎是更加美观了。一旦进入 Wikipedia,很难再关闭,一个词条连着多个词条,了解一个东西的时候,不知不觉就打开了许多新的标签页。

反观现在的大多数网站,外部链接变得更加稀少,或者压根就不提供外部链接,只想让访客留在自己的网站里,避免流量流失。这就是我为什么喜欢逛博客的原因,现在每天浏览的资讯网站只有 IT 之家,剩余几乎都通过 RSS 阅读博客,包括自己写博客,需要链接到其他网站时必然会链接,就比如今天这篇文章,无意间就在文字中分享了 Raptitude 博客。再或者昨天陈仓颉在群里分享的 Floor796,这是一个展示了来自各种作品的角色在一个巨大空间站第 796 层的生活,许多角色的还原度极高,点击每个角色会显示对应的出处,视频链接或者图片链接。博客圈是个圈,从一个博客跳转到另一个博客,兜兜转转还会回到原来的地方。

过去的互联网完全由网站组成 - 第2张图片

现在的互联网似乎是一团糟,互相限制和拦截,人们更加倾向于大型的社交平台,社交平台内部又存在各种限制,比如在马斯克手下的 X 中,如果帖子中含有外部链接,曝光度则会降低。

或许是因为昨天看到这篇文章,也或许是因为很早之前的想法,今天给博客做了一个微小的调整,将原先使用 post_ID 形式的固定链接修改成 post_name 的形式,本来还想找一个插件,自动将标题翻译成英文并设置成固定链接,转念一想,翻译虽然更准确,但自己编辑更有意义,更能记住文章写了什么,post_ID 只对系统有意义,于我而言只是记不住的编码,而文章标题则是更加重要。具体的步骤不多记录,主要分为三步,导出文章 ID、标题和链接,手动或自动翻译成英文,导入数据库,通过 SQL 语句进行替换,最后再设置重定向,大部分都参考了 Ouroboros 的文章《批量实现WordPress固定链接的中译英与重定向》进行操作。

The old internet is still out there though, beneath and between the elevated freeways, but you probably have to surf your way there.

旧的互联网仍然存在,在高架公路的下方和之间,但你可能需要自己冲浪才能到达那里。

过去的互联网完全由网站组成》最先出现在印记

重要通知: 弃用 FeedBurner RSS 请改用 https://justyy.com/feed

最近我发现原本的 RSS(/rss、/feed)没有按时更新。 [caption id="attachment_5288" align="alignnone" width="351"]rss rss[/caption] 进一步检查后发现这些地址都被 301 重定向到了 FeedBurner(https://feeds.feedburner.com/zhihua-xblog),而 FeedBurner 已经久未维护,偶有抓取失败或延迟,导致读者无法及时收到新文章。 造成这次重定向的原因是我们使用的第三方主题/插件(mytheme)里曾经内置了将站点 feed 转发到 FeedBurner 的功能。 当时之所以做 301 转向,是为了节省服务器带宽并统一订阅链接。 但现在服务器已经升级,带宽与性能不再是主要问题,因此不再需要通过 FeedBurner 做中转。 更糟糕的是,外部订阅器或旧配置在访问 /feed 时被持续重定向到 FeedBurner,如果 FeedBurner 自身抓取不到最新源,就会出现更新停滞或重复重定向的风险,极端情况下甚至可能出现重定向环(redirect loop)。 为了避免订阅丢失或链接异常,我们决定弃用 FeedBurner,并将本站的官方 RSS 源迁回自有域名。 请所有读者、RSS 订阅器和外部引用尽快把订阅地址改为: https://justyy.com/feed 如果你在使用 Feedly、Inoreader、邮件订阅或其他 RSS 客户端,请把原来的 FeedBurner 地址替换为上面的新地址,以确保你能及时收到更新。 如果你在网站或第三方平台上嵌入了本站的 RSS 链接,也请尽早更新为 https://justyy.com/feed,以免未来出现不可预期的中断。

用 FeedBurner 的好处

FeedBurner 由一家初创公司在 2004 年开发,2007 年被 Google 收购。FeedBurner 在 2000 年代非常流行,它的主要优点包括:
  • 统一和美化 RSS 输出:让各平台的 RSS 格式一致,订阅链接固定。
  • 订阅统计:可以看到每日订阅人数、来源与点击数。
  • 邮件推送功能:自动将新文章通过邮件发送给订阅者。
  • 广告功能:早期支持 AdSense for Feeds,在 RSS 中插广告获利。
  • 节省带宽:FeedBurner 缓存内容,订阅者访问时不会直接访问原站。
这些特性在当年是 WordPress 等博客系统无法原生提供的,因此 FeedBurner 成为了许多博主的默认选择。

用 FeedBurner 的坏处

然而,随着时间推移,FeedBurner 已经不再更新,甚至部分功能被 Google 下线,带来了以下问题:
  • 功能残缺:订阅统计、邮件推送等功能已被停用或不稳定。
  • 数据不准确:订阅数与阅读数常年不更新。
  • 影响 SEO 与品牌归属:订阅链接属于 FeedBurner,而不是你自己的域名。
  • 更新延迟:FeedBurner 抓取源可能延迟几小时,无法实时同步。
  • 潜在风险:如果未来 FeedBurner 服务终止,订阅者将全部丢失。
如今的 WordPress 已经具备完善的 RSS 功能,且现代工具(如 Mailchimp、Jetpack Subscribe、Substack)可以提供更强的推送与统计能力。 因此,继续依赖 FeedBurner 已经没有意义,反而会成为隐患。

总结与迁移建议

如果你还在使用 FeedBurner,请尽快切换到自有域名的 RSS 地址。 这不仅能避免服务中断与重定向问题,也能让你重新掌控订阅用户数据。 本站新的 RSS 地址是: https://justyy.com/feed 请更新你的 RSS 阅读器、订阅源或网站引用,确保后续能继续收到本站的最新内容。 FeedBurner 在 2010 年是 RSS 的标准,但在 2025 年,它几乎已经是“废墟”。现在更推荐:直接用 WordPress 自带 feed + 现代邮件/自动化工具,让控制权回到你手上。 感谢所有读者的长期支持与理解。 [caption id="attachment_70167" align="alignnone" width="1472"]RSS更新延迟一周,我得登陆FeedBurner强制Update一下 RSS更新延迟一周,我得登陆FeedBurner强制Update一下[/caption]

相关文章:

  1. 2025年10月10号币圈黑天鹅: 要想一直在牌桌前就不要玩杠杆/合约 只要不加杠杆,你就是安全的:除非你有能力承担损失,否则任何人都不应该使用杠杆。即使没有杠杆,加密货币的波动性也已经足够大了。 You are safe as long as you don’t do leveraging: No one should be...
  2. 个人网站Adsense广告申请通过: 需要最少15篇文章 我的个人网站 zhihua-lai.com 本月通过了 Adsense 审核,终于可以再次放置广告,赚些零花钱了。 其实,最初 Adsense 账户通过审核后就能直接放广告,但后来规则变得严格了。如果一个网站长时间没有放置任何 Adsense 广告代码,账户资格会被撤销。重新启用时,需要进行单独审核。如今,在 Google Adsense 中新增一个域名,也必须通过审核后才能投放广告。 为了让我的网站通过审核,我尝试了几次,但总是被拒,原因之一是必须要有足够的内容支持。例如,以前我做的工具网站 SlowAPI.com...
  3. 微信公众号(justyyuk)机器人支持 STEEM 查询啦 The wechat bot (justyyuk) now supports Inquiry for Steem Accounts. 之前把API给放出来, 能做的事情就很多了. 比如我就在我的公众号上加上了STEEM 查询. 查询的时候只需要给公众号发...
  4. 特朗普加关税的公式竟然是EXCEL里弄的? 这两天中美关税大战越演越烈,据说,特朗普加关税的计算方式竟然是直接在EXCEL电子表格里弄的,具体如下: 其中 I 是 Import,进口;E 是 Export 出口。 优美又实用的公式家族又添新成员 勾股定理: 欧拉恒等式: 牛顿运动定律: 爱因斯坦质能等价公式: 特朗普的“互惠关税”公式:,其中 I...
  5. 新的旅途 – 离别总是伤感的, 离开了一起创业的公司 2周前, 正式离开了一起创业的公司, 这公司是我博士毕业后的第一份正式工作, 待了8年多了, 离别总是伤感的. 我是9月初提的离职, 三个月 Notice Period, 最后的几周交接完工作确实没有什么压力了. 11月30号, 在公司最后一天, 公司有个习惯, 对于 Good...
  6. Minuet in C – 小步舞曲C Posted Youtube – 油管地址 孩子弹琴的时候最帅了. 我现在成了我儿子的粉丝了. Eric (Aged 6) is playing “Minuet in C” when...
  7. 儿子问我软件工程师的工作体验是怎么样的? 儿子问我软件工程师(Software Engineer)都是做什么的, 他很好奇我的工作内容, 我简单的说就是写代码+调试=解决问题. 正好那天是周五下午, 娃在上Papworth上钢琴课, 我一般都在车里剪视频利用起这个碎片时间. 我抱着笔记本在车里工作, 从年初就在忙一个大的改动, 忙了有两个多月, 终于差不多了, 两同事代码审核(Code Review)都通过了就差一些小改动, 所以我在车里还在努力, 根据收到的建议提交了代码...
  8. 伦敦海底捞火锅 (Hidilao) 好吃吗? 这一次去的是伦敦的海底捞(Hidilao)火锅. 已经开了有几年了, 这次等到英国疫情放开后才想着去试试. 以前听说人特别多, 得排队好几个小时, 这次大概是快中午12点去的, 给了个号码, 说大概要45分钟, 但感觉不到半小时就排到了. 伦敦的海底捞在地铁口(Piccadilly Circus)附近, 两分钟就到了, 不过感觉门面并不是很大, 一进门就是等候区, 用餐的在楼下二层....

腾讯EdgeOne免费国内CDN

2025年6月21日 13:12

最近各类公益CDN层出不穷,个人站长迎来新机遇。阿里、腾讯相继推出免费CDN套餐,门槛低、易上手。机缘巧合我拿到腾讯海外站EdgeOne的免费套餐兑换码,立刻上手体,整体表现非常流畅,配置简单,速度也令人满意。这篇也将简要说明一下我的使用感受。

静态网站优化方案

2025年2月27日 10:11

最近加了不少好友的友链,认识了许多网站上的朋友。由于众所周知的原因,有些国外服务在国内访问较慢,部分朋友的站点因此影响了国内用户的访问体验。为了帮助大家提高访问速度,我写了这篇文章,简单介绍了一些我所了解的网站加速方案,希望能够帮助更多朋友改善速度问题。

新年给博客迁新服

2025年1月6日 22:48

✨1/8日更新:3天AWS新服体验不佳,吃灰已久的Jetpack宕机监控功能3天下来跳了几次,已迁至阿里云港服。从 🇸🇬🇯🇵 再到 🇭🇰,博客站物理位置离自己更近了👏


博客重新上线时用的是Amazon Lightsail最低标准,配置是512MB内存 2vCPU,每月3刀,一个WordPress小博客站点够用了。用了一段时间有了折腾后发现不够用,就单单一次上传多个图片就能给整爆失联,得重启服务器恢复。后来干脆快照形式搬迁至1GB内存 2vCPU配置,每月5刀,用到现在没出现什么问题,期间亚马逊AWS还涨过一次价至7刀。

以上用的实例位置均在新加坡,期间有博友发现其无法畅通访问得挂梯子并告诉我(其实我自己用的网络环境中并没有遇到过,网络运营商处理这些在我看来有点玄学)。之后就心念着想换位置,理想位置是香港,毕竟是没有备案的最佳选择。还有一个想换的原因是用Bitnami栈打包的Apache服,怎么说呢,Bitnami非常好非常安全非常稳定,但对我来说太麻烦了,修改一些文件权限要整来整去,一些服务版本的更新还得大动干戈,就想换成原味。主要是自己的懒惰,就一直搁着。

新年嘛,就趁新年第一个周末给站点搬家。看了阿里云ECS和腾讯云CVM,最终选择了老东家亚马逊。亚马逊的EC2有港服,但没港服的Lightsail它更便宜!选了和原来一样的配置7刀/月,不同的是位置从新加坡换到了日本,离中国近一点哈哈,经过测试真的是快了一点~阿里云和腾讯云的轻量应用服务器也便宜且有港服,但当我看到“建站内容也是受限制的,出现违规域名会被封禁。”时总觉得会缺少点什么,虽然自己爱国守法,但还是算了,这些年使用过和正在使用的服全是外面的,也无所谓运营商玄学,就对搬回来这欲望并不是那么强烈。

周六上午就开好实例,用Debian12作服务器系统,习惯了Debian,很好。下午只需要旧服备份数据新服搭建环境后一气呵成。然而过程中出了一些状况,需要放下手头其他事,搁置了已经进行到一半的搬迁事宜。当时就连把域名解析回旧服ip从而恢复访问的操作都不想做,出现502 404 TIMED OUT之类已经无所谓了,因为儿子生病了。

周六当天儿子出现两次呕吐症状,第一次呕吐物比较少,里面有少许上午吃的水果。期间儿子还说过自己肚子痛痛,但我们仅凭他当时精神状态很正常,并就有没太多处理,只是揉揉肚子和各种无知的揣测原因。隔三四个小时后出现第二次呕吐,我们这时才意识到问题的严重性,并立马带他去医院,医生给的诊断结果是小儿病毒性肠炎。晚上儿子就出现发热症状,又是一个不眠夜。第二天还在发热,但属于低烧范围,已经不会再呕吐,也说肚子不痛痛了,状态也不错。

周日下午才有完全属于自己的时间接着去处理搬新服后续的事,算是比较顺利。出现问题是服务器莫名过载让网站无法访问,SSH也连接不上且持续很长时间,得重启服务器恢复。线索来源于“PHP message:Connection refused”,先排查插件发现W3TC所使用的缓存方式会导致此问题,Redis与Memcached都试过但问题依旧,干脆先停用,反正新服速度不错。病根应该是php,先搁置,等有空再处理~ //已解决,PHP权限问题

Lightsail真的很Light很轻量,CPU给压的死死的,便宜嘛,这货持续高负载就卡挂。属于突增型,就是说你平时使用CPU的利用率低于10%时(性能基准,实例配置不同基准百分比不同),能积累一种“能量”,当CPU利用率高于10%时,累积的“能量”就会消耗,如果持续高负载直至“能量”耗尽,CPU最大利用率就会压回10%,这就是为什么会挂掉的原因。以上是我对突增型服务器的理解,也罢,够用!

2025年了,看到大家都在写总结,晒清单,立新年Flag,由衷佩服大家的行动力,这是身为一个博主应该拥有的积极人生态度啊,反观自己真的是弱爆了。我属于是佛系,博客更新频率低,写的东西也属于肤浅的记录。时间是有的,陪小朋友、玩游戏、刷手机是我工作时间以外最放松的时候,所以不想“浪费”在写博文上。偶尔打开Follow看看大家写了啥,说真的点开订阅也成为另一种心理负担,因为每次点开后这么多的未读文章,每篇都想点进去瞄一眼,这时间就刷刷走了~

以阅读体验为核心的网页宽度设计策略

2025年9月6日 16:01

近期接到几位老铁的吐槽,建议加宽网页的主内容宽度和图片尺寸。及时反思和保持进取,当晚我就翻看了更新日志,发现当前博客的框架和页面宽度设定,可以追溯到2017年的版本,8年了,虽然2024年曾微调过一次。

但调整到多宽最合适,目前主流设备分辨率是多少,图片过大的影响,都需要逐一再考量。没有绝对完美的方案,以自己的内容特点、设计风格和个人喜好出发,我分享一下自己的考虑。


技术调研

 

当前主流分辨率格局

PC 端:多分辨率并存,超宽屏渗透率提升。

  • 1080P(1920×1080) 仍为主流,占比约 56%,尤其在办公场景中占据主导地位。
  • 2K(2560×1440) 增长显著,占比 20.06%,成为游戏和设计用户的首选,超宽屏(如 3440×1440)占比达 22.12%,适合多任务处理。
  • 4K(3840×2160) 占比 4%,主要应用于高端影音和专业设计领域,需配合高刷新率屏幕(如 120Hz+)。

 

移动端:折叠屏重构生态,高像素密度成常态。

非折叠屏:主流分辨率集中在 1080×2400(如小米 Redmi Note 14 系列),中高端机型普及 1.5K(2400×1080)屏幕,像素密度(PPI)普遍超过 400。

折叠屏:

  • 外屏:如荣耀 Magic V5 外屏 2376×1060(6.43 英寸),OPPO Find N5 外屏 2616×1140(6.62 英寸),需适配窄比例布局。
  • 内屏:分辨率普遍在 2K 以上,如华为 Mate X5 内屏 2480×2200(8.03 英寸),需处理平板级内容展示。
  • 动态视口:移动端浏览器地址栏动态伸缩导致传统 100vh 失效,建议使用 dvh (动态视口高度)单位。

 

较理想页面宽度策略

PC 端:限定最大宽度,兼顾可读性与兼容性。

  • 内容区宽度:建议采用 1440px 作为基准,既能覆盖 90% 以上的 2K 屏幕,又避免 4K 屏幕下的过度拉伸。
  • 弹性布局:使用 max-width: 1440px  +  margin: 0 auto 实现居中,两侧留白区域可填充背景色或平铺纹理。
  • 超宽屏适配:对 3440×1440 等超宽分辨率,可采用 1600-1920px 最大宽度,配合分栏布局提升信息密度。

 

移动端:设备无关,以逻辑像素为基准。

  • 设计稿尺寸:采用 375×812px(iPhone 13 Pro)作为基准,适配微信小程序等主流 H5 环境。
  • 容器查询优化:对折叠屏内屏(如 7.95 英寸 2352×2172),通过 @container 规则动态调整布局,例如当容器宽度≥768px 时切换为双列网格。

 

自适应设计技术方案

媒体查询:

  • 移动端优先:默认布局适配 320-767px,通过 @media (min-width: 768  px) 逐步增强。
  • PC 端断点:768px(平板)、1024px(窄屏 PC)、1200px(标准 PC)、1440px(2K)、1920px(4K)。

弹性单位:

  • 文本:使用 rem 配合根字体大小动态缩放,如 html { font-size: 62.5  %; } (1rem=10px)
  • 容器:采用 vw(视口宽度百分比)或 cqw (容器宽度百分比),例如 width: 80cqw 表示容器宽度的 80%。

布局系统:

  • Flexbox:实现导航栏、卡片列表等一维布局。
  • Grid:处理复杂二维网格,如电商产品列表。
  • 容器查询:替代传统媒体查询,实现组件级自适应。

图片:

  • 响应式加载:使用 srcset 和 size 属性提供多分辨率图片,为不同屏幕和布局提供不同尺寸的图片源,让浏览器自动选择最合适的一个。
  • WebP、​​AVIF 格式:压缩率比 JPEG 高 25% 以上,支持透明通道,推荐作为默认格式。

字体:

  • 抗锯齿:使用 -webkit-font-smoothing  : antialiased 提升小字清晰度。
  • 可变字体:通过 font-variation-setting  s 动态调整字重和宽度,适配不同屏幕密度。

布局切换:

  • 折叠时:采用单列布局,导航栏折叠为汉堡菜单。
  • 展开时:切换为双列网格,左侧展示主内容,右侧显示辅助信息。

技术总结

确定页面宽度时,通常考虑固定宽度自适应(全屏)宽度两种策略。选择时需考虑目标用户群体。若用户多使用高分辨率设备,可优先考虑1200px;若需兼容旧显示器,则960px更稳妥。

  • 首先PC端建议以 1440px 为基准,采用弹性布局 + 容器查询,覆盖 1080P 至 4K 分辨率。为容器设置一个 max-width: 1200px; (或其它合适值,设置1200px是保证页面有一定的留白),同时设置 width: 100%; 。这样内容区在小屏幕上能撑满空间,在大屏幕上又不会无限拉长而影响阅读。
  • 其次是移动优先,使用 dvh 和 cqw 单位,深度适配折叠屏多形态,毕竟现在使用移动设备的频率更高。
  • 最后是技术问题,采用 弹性布局(Flexbox) 和 网格布局(Grid),通过使用容器查询定义断点、动态视口单位、WebP 图片、可变字体等新特性的组合应用保持先进性。

设计调研

平衡阅读的舒适度和图片的展示效果,这是一个非常经典且重要的问题。

为什么不是全屏宽度?

人类视觉在阅读长段落文本时,有一个舒适的视线移动范围。如果一行文字过长(例如在1920px的大屏幕上铺满),会产生以下问题:

  • 容易串行:眼球需要大幅水平移动,从行尾跳回到下一行的行首时,很容易找错位置,导致阅读效率下降和疲劳感增加。
  • 难以聚焦:过长的文本行会分散读者的注意力,难以保持对内容的专注。
  • 美学上的不协调:大面积的空白(如果只是文本)反而显得空洞,不够精致。

经典的排版理论建议:每行容纳 45-75 个字符(包括空格) 为最佳阅读体验。对于常见的16px字体大小,600px - 800px的容器宽度恰好能落在这个黄金范围内。

 

“舒适单行字数” 的底层逻辑

阅读时,我们的眼球不是平滑地移动,而是进行一系列快速的“跳跃”(称为“眼跳”,Saccades)和在单词上的短暂“停顿”(称为“注视”,Fixations)。纸质书的单行字数设计,本质是遵循 “视觉追踪效率” 和 “阅读疲劳阈值” ,这一点与网页文章排版一致:

  • 当单行字数 少于 20 字 时:视线需要频繁上下移动(“换行太密”),容易打断阅读连贯性,尤其长文本会明显增加疲劳感;
  • 当单行字数 多于 50 字 时:视线横向扫描距离过长,容易找不到下一行的起始位置(“串行”),且大脑处理单行长文本时,记忆负荷会增加,导致阅读效率下降;

最佳区间(25-45 字):既能保证每一行的信息密度,减少换行频率,又能控制视线移动距离,符合人眼 “水平舒适扫描范围”(约 15-25 厘米,对应中文 25-40 字的宽度)。

 

图片越大越好?

​​“理想”的图片宽度没有一个唯一的固定值,但它有一个明确的决策框架​​。这个框架需要在​​视觉清晰度(Fidelity)​​、​​加载性能(Performance)​​ 和 ​​用户体验(UX)​​ 三者之间取得最佳平衡。图片过大过小会有以下常见问题:

  • 图片太大:加载过久,速度体验不佳,消耗大量用户流量​;存储压力,需要更大的空间;屏幕过满,需要拖动滚动条,缺少页面呼吸空间
  • 图片太小:太小气,影响博主格局体现;看不清,模糊与锯齿,视觉体验不佳;损害专业性与信任度,设计的灵活性降低。

理想的图片宽度:在用户的浏览器中,渲染尺寸的 1.5 到 2 倍(针对高DPI屏幕),并且使用现代格式进行高效压缩。​这意味着它是一个​​动态值​​,取决于用户的设备、视口大小和网络条件。


设计总结

居中布局:1000-1200px左右的内容整体在浏览器中居中,两侧自然会留出空白区域。这些留白(Negative Space)不仅让页面呼吸感更强,也能更好地将读者的视线聚焦于核心内容。

使用相对单位:可以考虑使用  ch (字符宽度单位) 或  rem 来定义内层容器的宽度,这比固定像素更具弹性。例如  max-width: 65ch; 是一个非常推崇的用于文本排版的值。

文字处理:

  • 文本宽度(Line Length):主要内容宽度控制在 65ch 左右(​​600px - 800px​),控制在一行45-75 个字符内。一般32 开纸质书一行是28-35 字,学术专业类书籍是35-45 字。
  • 字体大小(Font-size):正文通常使用  16px - 18px ,对于阅读更友好。
  • 行高(Line-height):设置为字体大小的1.5 - 1.8倍,例如  1.6 是非常舒适的选择,1.8 就更加宽松点。

图片处理:

  • 确保图片设置了  max-width: 100%; 和  height: auto; ,以便在移动端等小屏幕设备上能按比例缩放。
  • 对于高分辨率屏幕(如Retina屏),可以使用  srcset 属性提供更清晰的图片版本。

其他增强阅读体验的设置:

  • 字体颜色与对比度:正文不要使用纯黑( #000 ),尝试深灰色(如  #333 或  #444 ),背景色为纯白( #FFF )或极浅的灰( #F8F8F8 ),对比度适中,长时间阅读更不易眼酸。也可以选择一个浅黄色或浅绿色作为底色。
  • 去除视觉干扰:去掉多余修饰图片,特别是闪动的图片或文字,去掉鼠标指针动画、点击动画等。

最终策略

针对我当前的博客设计,大概的改造点如下:

  • 页面最大宽度调整为800px,保持现有行距(1.8倍)不变,主内容字号调整为17px,原多列展示内容自适应加宽。
  • 文本最大宽度为800px,就是一行45个字符左右。文本太长看着很累,控制在45个字左右是我比较倾向的方案。
  • 图片控制最大宽度为800px,默认文中插入全尺寸图片(1200px),1.5倍勉强应对高DPI屏幕。(为避免生成过多尺寸的缩略图,已关闭 WordPress 自带的响应式图片功能,并仅生成必要尺寸。原图尺寸有条件保证1600px以上宽度更为合适。)
  • 取消图片原图链接,取消图片 lightbox 效果,距离 NO JS 更近了一步。
  • 精简媒体查询的适配,只考虑适配 @media (max-width: 767px) 

理论性的东西要谈是谈不完的,技术实现的,平面排版的。如果不考虑别人看的体验,那怎么高兴怎么来。

文中数据从网络获取,数据和方法仅供参考,如有纰漏,欢迎指正。

一个平平无奇的 WordPress 评论等级插件

2025年11月16日 17:12

对于博主而言,能收到读者的评论留言并与之互动是一件很幸运的事情。前段时间,偶然看到两篇文章,分享了如何给评论者增加等级徽章,以此来提高交互乐趣。受此启发,我制作了一个 WordPress 插件,该插件能根据访客的评论留言次数,在其昵称旁显示一个专属等级徽章。插件的操作简单、设计简洁并提供了方便的后台自定义功能。

效果展示

评论区效果
后台界面

特点

  1. 操作简单。下载zip文件,在后台安装插件即可。相比参考文章中,去修改 functions.php,使用插件对于小白更加友好,并且不会因为主题更新而导致自定义代码丢失。
  2. 根据邮箱次数,自行判断该网友的等级。VIP1: 2-4次;VIP2:5-9次;VIP3:10-24次;VIP4:25-49次;VIP5:> 49次。
  3. 增加后台管理页面。wordpress 仪表盘 - 设置 - 评论等级 中可以进行查阅和自定义配置。
  4. 支持“绿色通道”。允许你为某位特定的网友手动设定 VIP 等级,例如跳过自动晋升,直接将其指定为 VIP5 。
  5. 自定义徽章颜色和名称。默认的徽章颜色和名称是按照我个人博客风格设置的,你也可以在后台手动修改为你喜欢的颜色和文本,以便更好地适配你自己的主题。

下载与安装

前往 GitHub 下载 zip 安装包,并在 WordPress 后台的「插件 – 添加插件」中上传安装。

参考文章

感谢这两篇文章提供的思路和参考代码,才让我和 AI 能如此顺利完成该插件的制作。

小结

为评论添加等级标识虽然能增添一丝趣味性,但同时我也很担心会破坏博客原有的简洁美感。所以,我自己最终是否会长久使用这款插件,目前还是个未知数。 不知道大家对这个小标识有何感想?是否会觉得它有些多余,会影响美观?欢迎在评论区留言分享你们的想法🙏!

一个平平无奇的 WordPress 评论等级插件最先出现在Jack's Space

记录本站的一些优化

2024年9月13日 18:30

之前搭建了个本地搜索,大约1.74M,让网页访问拉慢了,但是没办法,不然搜索不能用。

现在想办法把加载速度从其他地方找补一点回来。

使用图片延迟加载

github地址: hexo-lazyload-image
使用下面指令安装
npm install hexo-lazyload-image --save

配置如下,loadingImg需要注意要添加站点url,否则会出现页面内的post找不到loading图问题

1
2
3
4
5
lazyload:
enable: true
onlypost: false
imageCDN: # eg https://same.cdn.com/
loadingImg: # eg ./images/loading.gif

在这里可免费制作loading图 loading.io

资源压缩

Hexo-minify
Hexo-minify 是一款 Hexo 压缩插件,它可以压缩 HTML、CSS、JS、Font、Image(jpg,png,gif,webp,svg)

网页预加载

InstantClick CDN
当用户的鼠标悬停在一个链接上时,InstantClick 就会开始预加载该链接指向的页面内容。一旦用户点击这个链接,新页面几乎可以瞬间显示出来,因为大部分内容已经被预加载好了。它通过在后台异步加载页面资源,减少了用户等待页面加载的时间。

❌