雨夜寻晴天

在维护公司官网的过程中，我遇到过一个典型的静态网站开发痛点：“在我的电脑上是好的，为什么在你那里就报错了？” 经过排查，罪魁祸首往往是 Hugo 版本不一致。 为什么 Hugo 版本管理很重要？

在参与开源项目（如 Tauri）或对安全性有要求的团队开发中，你可能会遇到这样的情况：提交的代码在 GitHub 上显示为 "Unverified"（未验证），甚至因为没有签名而被禁止合并。

前端组件分散在不同仓库，人工发布易错、流程冗长； 需要 “改版本 → 自动构建发布 → 自动同步配置” 的一条龙流程； 通过 GitHub Actions + 集中配置文件，搭建一套稳健、可扩展的发布

在做桌面应用 coco-app（React 18 + Tauri）时，遇到一个肉眼可见的体验问题：搜索结果渲染出来后，默认选中的第一项会 “慢半拍” 才高亮，导致 UI 有轻微闪动。这篇文章分享定位过

在桌面端应用中，我们为 SearchChat 设计了一种「紧凑模式」： 正常状态下窗口高度较大 当一段时间无操作后，窗口会自动收起到紧凑高度（例如 84px） 收起动作

在日常的前端工程化实践中，GitHub Actions 自动化发布 NPM 包是提升效率的常用手段，但稍不注意的配置细节就可能引发诡异的问题。本文将分享我遇到的「Filter 组件发布时同一版本重复发

前端有一个经典问题： 所以正确的前端方案不是 “给外层容器加 overflow”，而是：尽量在 iframe 自己层面兜底 + 同源时向 iframe 内注入 CSS。 本文只聚焦前端实现，不展开前后

最近在项目里遇到两个来自 Radix Dialog 的控制台提示： 它们不是 “功能错误”，但属于 无障碍（a11y）级别的警告：Radix 在开发环境主动提醒你对话框缺少 “可被屏幕阅读器正确理解。

最近在给 npm 包做 CI 发版时，突然开始频繁失败，npm 的提示也非常直白： 一句话总结就是： 现在就记录一次完整的 CI/CD 改造过程，包含： npm 新规则到底改了什么...