雨夜寻晴天

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

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

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

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

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

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

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

在做跨平台桌面应用（Tauri / Electron / Flutter Desktop）时，“窗口尺寸/位置在不同电脑上不一致” 是非常高频、且非常隐蔽的坑： 同一份代码，在你电脑上完美居中，在同事

为什么 Esc 会变得“不可控” 在 Coco 里，Esc 同时承担了很多“退出/关闭”的职责： 退出输入（Input/Textarea）编辑态 关闭弹层（Popover / 菜单） 关闭历史面板..