个人网站

本文介绍了作者在管理个人网站和 B 站信箱过程中经历的反思与回归。作者首先描述了 B 站信箱因评论被顶到热门而充斥陌生人的无效留言，使其难以分辨真实交流，转而通过回看视频评论区逐条回复来寻求真实感。接着，作者回顾了个人网站建设中因添加过多定制功能如毛玻璃卡片、深色模式等导致界面臃肿混乱，最终意识到最初的主题简洁完整，决定换回旧主题以回归初心。由于缺乏 Git 记录，作者借助 MATUGEN 生成配色方案，并利用 GLM 将配色写入主题，预期呈现更明亮清新的效果。同时，作者保留了部分实用功能如 CSS 覆写规则、404 页面自动修复、友链模块和评论区头像解析，实现删繁就简的融合升级。最后，作者反思过度美化的教训，强调简洁是需学习的克制，并建议访客在重新访问前清空浏览器缓存以避免样式冲突。

本文介绍了作者在使用 Cloudflare 服务时遭遇的邮箱显示异常问题及其解决过程。凌晨作者发现网站前台邮箱全部变为 [email protected]，经 AI 提示得知这是 Cloudflare 内置的电子邮箱地址混淆功能，旨在防止爬虫抓取真实邮箱减少垃圾邮件。文章随后阐述了 Cloudflare 作为域名托管与 CDN 加速服务商的背景，以及该功能的底层实现原理：在数据传输层修改 HTML 源码将邮箱替换为占位符，并注入加密 JavaScript 脚本，在安全环境下动态还原。然而作者的网站采用了 PJAX 技术实现局部刷新，导致该脚本在页面切换时不会执行，邮箱始终显示占位符，国内访客无法看到有效联系方式，造成沟通障碍。作者最终通过 Cloudflare 仪表盘关闭该功能，但凌晨操作时遭遇 API 返回 504 错误，疑似后台维护，直到星期六早上才成功关闭，网站联系方式恢复正常。

本文介绍了作者针对静态博客实现邮箱订阅推送的解决方案。文章首先指出现有方案（如基于 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 等已有代码，技术路径清晰，体现了技术服务于人的理念。

本文介绍了作者在修改 Butterfly 主题网站封面布局时，因无法通过覆写规则实现需求，转而 Fork 主题仓库直接修改源代码，却因长期未操作导致环境变化而失败。情绪冲动下，作者先删除仓库，又误删了整个网站文件夹，导致包含 60 多篇空白草稿的 _drafts 文件夹彻底丢失——这些草稿本是未来一年的选题灵感来源。作者反思了将草稿库加入 .gitignore 仅影响版本控制、无法保护本地文件的教训，并对比了此前因缺乏备份丢失 100 多篇文章文档站的更惨痛经历。文章还提到树莓派因承担评论服务和图床导致流量异常（下传 120 多 GB、上传 80 多 GB）的过往问题。最终作者依靠自己记录博客的习惯重新恢复部分脚本逻辑，但承认未来更新速度会变慢、选题难度加大。本文警示读者备份要彻底，避免选择性忽略文件。

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

本文探讨了邮箱与微信作为工作沟通工具的优缺点。文章指出，邮箱具备法律证据效力、正式性和可追溯性，但缺乏即时性，且多设备同步存在 IDLE 技术限制，导致消息推送延迟；微信即时性强、门槛低，但功能臃肿、隐私边界模糊，且碎片化沟通难以形成严谨证据链。作者认为两派观点各有偏颇，工具选择受制于职场环境与用户需求，理想方案是依据场景组合使用，但现实中难以实现。文章旨在为在两者间摇摆的用户提供参考。