代码展示

本文介绍了作者在 B 站发现“我的世界小站”功能后，对 MC 玩家社区需求的分析以及通过技术手段批量探索小站的过程。作者认为玩家真正缺失的不是论坛形式，而是优质资源和联机玩伴。为了了解 B 站共建了多少个小站，作者尝试编写爬虫，但发现网站采用 Vue 等前端框架进行客户端渲染，普通 HTTP 请求无法获取完整 HTML。随后利用 Playwright 库调用无头 Chromium 浏览器，模拟真实用户加载页面，等待 JS 执行完毕后提取 div.name 元素内容。脚本从数字 1 开始递增访问，遇到超时（视为 404）自动停止，成功获取到共 72 个小站的名称列表，包括艾尔登法环小站、Switch 小站、佛学学习分享小站等。文章还分享了脚本的 UA 伪装、依赖库配置、以及开发者对开源文档的考量，最终为读者提供了一个可直接运行的自动化工具，并鼓励对 B 站小站生态感兴趣的用户收藏使用。

本文介绍了作者在处理 Waline 评论系统邮件通知失效问题时，通过排查与配置 DMARC 记录最终解决邮件被拒收或误判为垃圾邮件的过程。作者在周六晚上发现未收到访客留言的邮件提醒，起初怀疑是 Q 邮箱容量超限，但清理收件箱后问题依旧。随后查阅 Resend 后台建议，注意到“未配置 DMARC 策略”是导致邮件被主流服务商拒收的关键原因。通过咨询 DeepSeek 了解到，DMARC 是 1 种用于邮件验证的 TXT 记录子域名，相当于发件方向邮箱服务商提供的官方授权说明，自 2024 年起各大邮件服务商已大幅收紧收信规则。作者在 Cloudflare 上为域名添加了 1 条名为 _dmarc 的 TXT 记录，并填写了包含 v=DMARC1; p=none; 等参数的值，同时将 rua 地址替换为自己的邮箱以接收报告。文章还提醒 DNS 记录修改后需要等待传播生效，且 Resend 会自动重试失败的邮件发送，无需过度焦虑。最终通过此配置解决了邮件提醒问题。

本文介绍了网站重构或迁移后路径变化导致搜索引擎索引失效的问题，并给出了一种基于前端脚本的路径纠错解决方案。文章描述了当用户访问错误路径时，浏览器会展示预设的 404 页面，然后通过脚本获取当前路径，并与从 sitemap.txt 中提取的合法路径列表进行语义匹配，利用 Levenshtein 距离和路径层级评分找到最可能的正确路径，并在 5 秒后自动跳转。还提供了调试函数 error_location 用于本地测试。文章详细说明了编写脚本过程中遇到的坑，例如 Butterfly 主题的 404 容器类名、Hexo 生成的 sitemap 包含 index.html 后缀问题，以及如何通过另一个脚本去除 index.html 实现干净跳转。最后给出了在 _config.butterfly.yml 的 inject 中引入脚本的配置示例。该方案有效保留了 SEO 索引，提升了用户体验。

本文介绍了 Butterfly 主题中首页文章列表高度不统一的问题及其解决方案。由于博客每页显示固定篇数（如 10 篇），末页文章数量不足时，列表容器高度会大幅缩减，导致底部大量空白，影响视觉一致性。为解决该问题，文章提供了一种基于 JavaScript 的动态补齐方法：通过 fillRecentPostItems 函数检测 .recent-post-items 容器内实际文章条目数，若少于目标值（如 10），则自动追加对应数量的隐藏 div 元素（visibility: hidden），使容器高度始终与满篇数保持一致。该逻辑还通过监听 pjax:complete 事件兼容 PJAX 无刷新加载，确保页面切换后自动执行补齐。同时指出，在 index_layout 参数为 4 或 6 的特殊布局下，由于文章条目高度依赖封面图片，纯隐藏标签会导致高度不一致，因此需要额外添加空封面占位元素。最后说明如何通过主题的 inject 配置将脚本注入页面底部，无需修改核心文件，便于维护升级。该方案有效解决了分页高度不一致的布局问题。

本文介绍了作者针对静态博客实现邮箱订阅推送的解决方案。文章首先指出现有方案（如基于 GitHub Issues 的推送）存在重复推送、依赖读者 GitHub 账号等问题，随后提出利用 GitHub Actions 的 Cache 系统记录已推送文章链接，从而避免重复。作者详细说明了整体流程：通过定时触发 Actions，运行 Python 脚本抓取博客 RSS 地址中的最新文章，解析标题、摘要和链接，并与缓存文件比对，若为新文章则生成 HTML 邮件，并通过 SMTP 协议密送订阅者。所有敏感配置（如 SMTP 凭据、邮箱列表）均存入 GitHub Secrets 以保护隐私。文章还给出了完整的 YAML 工作流配置和 Python 脚本示例，支持自定义邮件模板标签。最后，作者推荐使用 Resend 等免费 SMTP 服务，并列出需要创建的 Secrets 参数，方便读者 Fork 仓库后直接使用。该方案实现了真正的不重复邮箱推送，适用于任何拥有 RSS 输出的静态博客。

本文介绍了如何解决评论区默认 Gravatar 头像导致大量匿名用户使用相同默认图标、破坏页面视觉一致性的问题。作者首先指出大部分评论系统基于 Gravatar 机制，但国内用户很少注册，导致评论区频繁出现蓝色背景的默认头像。最初的方案是利用 CSS 的 img[src=""] 属性选择器和 content: url() 声明直接替换头像地址，但发现 CSS 文件被浏览器或 CDN 缓存后无法即时更新，且随着无头像访客增多，维护成本极高。为此作者提出了更优雅的解决方案：将头像映射关系写成 JSON 格式，部署在 GitHub Pages 上，再通过自执行 JavaScript 脚本从服务器拉取该 JSON，动态生成 CSS 样式并注入页面头部，从而替换所有匹配的 Gravatar 头像。该方案不依赖特定评论系统，只要底层使用 Gravatar 机制均可适用。作者最终将此服务命名为“梁栋烨头像联盟”，并开放共享，同时鼓励读者自行搭建以完全掌控数据。文章还表示会为长期访客提供头像解析工单，帮助其获得专属视觉标识。

本文介绍了作者在网站优化过程中，重新关注友链功能并为其创造更大价值的思考与实践。作者在投入大量精力调整网站加载速度、排版布局和交互逻辑后，偶然通过社交媒体结识了一批新人博主并主动交换友链。然而，作者意识到传统友链页面容易被访客忽视，无法有效为小博主引流，因此设想在页脚以随机形式展示友链，使其更自然地触达访客。作者参考了安知鱼博客主题的类似实现，并基于此前编写的用于抓取友链数据的 JavaScript 脚本进行改造。脚本逻辑包括：在配置文件中添加空容器标签，页面加载后异步请求 /friends 页面 HTML，解析 DOM 提取第一个 flink-list 中的友链信息，过滤无效数据，再根据屏幕宽度（大于 768 像素显示 6 个，否则显示 3 个）随机抽取不重复的友链接，动态生成链接元素插入页脚。这一响应式设计避免了手机端布局错乱，同时充分利用电脑端空间，使友链从静态列表变为动态信息流，真正释放其引流价值。

本文介绍了作者在维护个人博客网站时发现字体拥挤、段落缺乏缩进导致可读性差的问题，并借助 DeepSeek 寻求解决方案的过程。通过分析，作者确定需要针对文章正文容器（article p 和 div#article-container p）添加 text-indent: 2rem 实现首行缩进，同时为全站 body 设置 letter-spacing: 0.1rem 以增加字符间距。随后，作者在 _config.butterfly.yml 主题配置文件中正确引用了自定义的 paragraph.css 文件，并利用 GitHub Actions 自动部署更新。文章还强调了在开发者工具中验证样式是否生效、以及清除浏览器缓存或强制刷新页面等常见排查步骤，帮助读者避免因配置遗漏或缓存导致修改无效的陷阱。最终，通过精准的 CSS 选择器和统一的间距设置，网站排版获得了“书卷气”般的舒适阅读体验。

本文介绍了作者如何利用 AI 技术为博客文章自动生成摘要，以解决主题默认截取前 500 字作为页面描述所带来的内容不完整、体验不佳的问题。作者借鉴了 CSDN 的 AI 摘要功能，基于已有的 Markdown 文件处理、API 调用与 Frontmatter 解析经验，设计并实现了 1 个自动化脚本。该脚本接收文章文件路径，读取内容后以 --- 为定位符提取正文，将正文发送给 DeepSeek 模型，并附带精心设计的提示词，要求生成以“本文介绍了”或“本文描述了”开头、字数超过 200 字、符合中英文空格规范的中文摘要。最后将 AI 返回的摘要作为 description 值插入到 Frontmatter 中。此脚本不仅能够提升 SEO 优化效果，更重要的是尊重访客的阅读体验，使他们能快速判断文章内容，实现更高效的浏览。整个实现复用 auto-tags.py 等已有代码，技术路径清晰，体现了技术服务于人的理念。

本文介绍了作者将网站说说功能从本地文件管理迁移到远程拉取架构，解决 Git 提交历史臃肿的技术债务。随后，作者重构了标签系统，编写了两个 Python 脚本：auto-essay-tags.py 批量调用大语言模型 API 为已有说说自动生成社交媒体风格标签，essay.py 则用于新增说说时自动获取时间、生成唯一 key 并调用 API 打标签，两者共用同一标签库 essay-tags.md。文章还探讨了在轻量级标签生成场景下，长上下文并非最优解——传递最小必要信息更高效，并质疑当前 AI 厂商依赖长上下文消耗 Token 的商业模式可能扭曲了技术发展方向。