一个叫HTMLcat的网站最近在前端圈子里小范围传开，页面很简单：42张便签式卡片，每张收录一条容易被忘记的原生HTML、CSS或JavaScript技巧，从clamp()到:has()选择器，从Popover API到还在实验阶段的CSS Grid Lanes布局，风格统一，读起来轻松。做这个站的是独立开发者Marco Mezzavilla，页脚只标了2026年，没有正式发布公告，是典型的个人副业项目。
真正值得说的不是这个网站有多可爱，而是它把成熟度悬殊的技巧摆进了同一套视觉语言里，却没给读者任何区分提示。对照Baseline和Can I Use的数据一查，问题就露出来了。
从广泛可用到实验阶段，一张卡片脸看不出差别
:has()选择器已经进入Baseline"广泛可用"状态，全球浏览器支持率92.66%，早就能放心写进生产代码。Popover API紧随其后，支持率91.49%，只是iOS Safari要到18.3版本才补齐完整支持。这两条放在卡片墙上没什么问题。
但同一份清单里还收了CSS Grid Lanes（也就是masonry瀑布流布局），这项特性至今没进Baseline，支持率仅10.55%，只有Safari 26.4以上版本支持，Chrome、Edge、Firefox默认都没打开。CSS自定义函数@function和corner-shape属性也没进Baseline，检索到的支持率都在68.05%左右——两个不同特性给出同一个百分比，这个巧合本身就值得怀疑，更稳妥的说法是"支持率都不到七成"，具体数字建议开发者自己去Can I Use再核一遍。
框架疲劳催生的收藏热，但收藏不等于验证
这类"原生技巧备忘录"不是新鲜物种。早年有HTML5 Please、You-Might-Not-Need-jQuery，逻辑都一样：前端框架越堆越重，浏览器原生能力却在Baseline计划的推动下一年年补齐，于是有人愿意把散落在规范文档里的冷知识整理成卡片，方便同行随手翻。这股"原生优先"的风气本身没问题，问题出在执行层面——把整理和验证混为一谈。
HTMLcat的页面上没有任何Baseline状态标注，也没有支持率提示，读者拿到的只是"这个特性存在、这样写"，至于能不能上线全靠自己判断。网站还开放访客投稿，内容会被编辑统一风格，这进一步模糊了"作者验证过"和"读者需要自行验证"之间的边界。
卡片一样轻松，特性一点不轻松。
需要提醒的是，检索资料里还出现过一版关于HTMLcat"产品方向"的设想，提到社区点赞分类、无障碍评审流程之类的功能，但对照实际抓取到的首页——只有About和Contribute两个链接，没有任何社区互动模块——那份设想明显是脱离现状的推测，不能当作网站真实功能来引用。
开发者该怎么用这类清单
- 提醒.照抄卡片示例代码前，先去Can I Use或MDN查一遍该特性的Baseline状态，尤其是Grid Lanes、CSS自定义函数这类仅Chromium支持的项目，贸然上线容易在Firefox或Safari用户那里直接失效。
对独立开发者社群来说，HTMLcat这类项目的价值仍然成立——它把分散的冷知识重新打包，降低了发现成本。但发现成本降低，不代表验证成本也跟着降低。真正决定一条技巧能不能进生产代码的，从来不是它有没有被写成一张好看的卡片，而是@supports能不能兜住、目标用户的浏览器版本分布是什么样。这部分工作，卡片墙替不了。