Now vibe coding, so learning hammer FE ?https://channel.meo-ai.comhttps://channel.meo-ai.com/posts/654https://channel.meo-ai.com/posts/654Mon, 01 Jun 2026 00:06:54 GMT<span class="post-title-source">《为什么我放弃Next.js和RSC，回归传统SPA与独立后端》</span><br /><br />标签：<a href="/search/result?q=%23%E5%89%8D%E7%AB%AF" title="#前端">#前端</a> <a href="/search/result?q=%23Web%E5%BC%80%E5%8F%91" title="#Web开发">#Web开发</a> <a href="/search/result?q=%23React" title="#React">#React</a> <a href="/search/result?q=%23NextJS" title="#NextJS">#NextJS</a> <a href="/search/result?q=%23React_Server_Components" title="#React_Server_Components">#React_Server_Components</a> <a href="/search/result?q=%23SPA" title="#SPA">#SPA</a> <a href="/search/result?q=%23%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1" title="#架构设计">#架构设计</a> <a href="/search/result?q=%23%E5%AE%89%E5%85%A8" title="#安全">#安全</a> <a href="/search/result?q=%23TanStack" title="#TanStack">#TanStack</a> <a href="/search/result?q=%23Hono" title="#Hono">#Hono</a><br /><br />总结：<br /><br />作者回顾了自己从Next.js忠实用户到拥抱App Router/RSC，最终回归传统SPA+独立后端的完整历程。文章深入分析了RSC架构带来的心智负担、序列化开销和安全风险，结合2025-2026年多起严重CVE漏洞，论证了将渲染框架与安全边界解耦的必要性，并分享了当前基于React Router+Vite+Hono的简洁技术栈。<br /><br />文章要点：<br /><br />1. <b>Next.js的黄金时代</b>：Pages Router时期心智模型清晰，服务端/客户端边界一目了然，文件路由简单易懂，部署零成本<br />2. <b>App Router带来的混乱</b>：Server/Client Component区分成为负担，"use client"指令传染性强，开发/构建/生产环境缓存行为不一致，服务端客户端边界变得不可见<br />3. <b>安全漏洞敲响警钟</b>：2025年CVE-2025-29927中间件绕过(CVSS 9.1)、2025年底RSC核心包10分满分漏洞CVE-2025-55182、2026年初多起Server Function DoS漏洞，攻击面集中在服务端渲染和反序列化环节<br />4. <b>TanStack并非避风港</b>：2026年5月TanStack遭遇供应链攻击，42个包被投毒，说明换框架不能免疫风险，减少依赖面才是关键<br />5. <b>序列化是根本原因</b>：RSC的"无缝"本质是分布式系统的序列化问题，函数、类实例、错误栈都无法透明穿越边界，反序列化不可信输入成为高危攻击面<br />6. <b>当前架构选择</b>：React Router框架模式+Vite纯SPA（仅营销页预渲染）+ Hono独立后端，API通过显式HTTP调用，无RSC负载，无服务端序列化<br />7. <b>安全设计原则</b>：认证授权在API层强制执行，前端中间件只做UX跳转，CORS/CSRF/验证码/限流全部在可控的后端实现，与渲染框架彻底解耦<br />8. <b>核心收获</b>：架构清晰可指认、无序列化税、前端攻击面趋近于零、后端语言自由选型、依赖更少爆炸半径更小——"无聊"在软件工程里是赞美<br /><br />URL：<a href="https://dev.to/zulikram/why-i-walked-back-from-nextjs-and-rsc-to-a-plain-spa-and-a-separate-backend-4k8p" target="_blank" rel="noopener" title="https://dev.to/zulikram/why-i-walked-back-from-nextjs-and-rsc-to-a-plain-spa-and-a-separate-backend-4k8p">https://dev.to/zulikram/why-i-walked-back-from-nextjs-and-rsc-to-a-plain-spa-and-a-separate-backend-4k8p</a>https://channel.meo-ai.com/posts/603https://channel.meo-ai.com/posts/603Sun, 19 Apr 2026 23:44:56 GMT<span class="post-title-source">《Claude架构图生成器：AI一键绘制专业系统架构图》</span><br /><br />标签：<a href="/search/result?q=%23AI%E5%B7%A5%E5%85%B7" title="#AI工具">#AI工具</a> <a href="/search/result?q=%23Claude_Skill" title="#Claude_Skill">#Claude_Skill</a> <a href="/search/result?q=%23%E6%9E%B6%E6%9E%84%E5%8F%AF%E8%A7%86%E5%8C%96" title="#架构可视化">#架构可视化</a> <a href="/search/result?q=%23%E5%BC%80%E5%8F%91%E6%95%88%E7%8E%87" title="#开发效率">#开发效率</a> <a href="/search/result?q=%23%E7%B3%BB%E7%BB%9F%E6%9E%B6%E6%9E%84%E5%9B%BE" title="#系统架构图">#系统架构图</a><br /><br />总结：<br />这是一款专为Claude AI设计的Skill工具，让用户只需用自然语言描述系统架构，即可生成精美的暗色系专业架构图。输出为独立的HTML/SVG文件，无需任何设计技能或额外软件，适合快速迭代和团队协作分享。<br /><br />文章要点：<br />- 零门槛使用：不需要设计基础，用大白话描述系统组件和连接关系，Claude就能帮你画出专业级架构图<br />- 多种输入方式：可以让AI分析代码库自动生成描述，也可以自己手写组件列表，还能直接问Claude要典型架构模板<br />- 精美视觉风格：采用暗色主题（Slate-950背景），组件按类型着色（前端青色、后端翠绿、数据库紫色、云服务琥珀色），自带网格底纹和JetBrains Mono字体<br />- 独立文件输出：生成单个HTML文件，内嵌CSS和SVG，任何浏览器都能直接打开，方便分享、打印或嵌入文档<br />- 实时迭代优化：生成后可以继续在对话中要求修改，比如"加上Redis缓存"或"调整布局"，Claude会即时更新图表<br />- 多平台安装：支持Claude.ai网页版（Pro/Max/Team/Enterprise）、Claude Code CLI、以及Projects知识库三种方式<br />- 丰富示例覆盖：内置Web应用（React+Node+PostgreSQL）、AWS无服务器（Lambda+API Gateway）、微服务（K8s+多语言服务）等典型场景模板<br /><br />文章URL：<a href="https://github.com/Cocoon-AI/architecture-diagram-generator" target="_blank" rel="noopener" title="https://github.com/Cocoon-AI/architecture-diagram-generator">https://github.com/Cocoon-AI/architecture-diagram-generator</a><a class="tgme_widget_message_link_preview" href="https://github.com/Cocoon-AI/architecture-diagram-generator" target="_blank" rel="noopener" title="Generate beautiful dark-themed system architecture diagrams as standalone HTML/SVG files. Works as a Claude AI skill. - Cocoon-AI/architecture-diagram-generator"> <div class="link_preview_site_name accent_color">GitHub</div> <img class="link_preview_image" alt="GitHub - Cocoon-AI/architecture-diagram-generator: Generate beautiful dark-themed system architecture diagrams as standalone HTML/SVG…" src="/static/https://cdn4.telesco.pe/file/FCIqr97nDGC4xaOGyvQT8gvaG0f2QgwotUInntcWFy40mp8q25gzesGcEy_R6V_I8-e0CkpZhuVkc8pEGQ2WJ0Pn5W610MD_Q0Rd8seuPl04Eh2ZEKWNKe3zxyv7wRFGaI4p2Mw00AiFOP4VEbKrEx6XPr4sACjsZlBDY-Ovt9FzpTUO-D36YwSyVi3txoBE2CoO_HghtcDknfTNxzCMIAfEhDIkPdsjsujk-TUexGv2Pncztdw1MNWbTSP3-ScDya_NM8icvv6ujcA1AfUfwXoQLKMA3VXszLKz_5itAYD4Wqgl88ckBgzEsf6MX4yuO1cCVIHiOsT209wdbmKZuA.jpg" width="1200" height="630" loading="eager" /> <div class="link_preview_title">GitHub - Cocoon-AI/architecture-diagram-generator: Generate beautiful dark-themed system architecture diagrams as standalone HTML/SVG…</div> <div class="link_preview_description">Generate beautiful dark-themed system architecture diagrams as standalone HTML/SVG files. Works as a Claude AI skill. - Cocoon-AI/architecture-diagram-generator</div> </a>https://channel.meo-ai.com/posts/599https://channel.meo-ai.com/posts/599Sat, 18 Apr 2026 08:12:54 GMT<span class="post-title-source">《垂直代码库：告别按类型分层，拥抱按业务域组织》</span><br /><br />标签：<a href="/search/result?q=%23%E5%89%8D%E7%AB%AF" title="#前端">#前端</a> <a href="/search/result?q=%23%E4%BB%A3%E7%A0%81%E7%BB%84%E7%BB%87" title="#代码组织">#代码组织</a> <a href="/search/result?q=%23%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1" title="#架构设计">#架构设计</a> <a href="/search/result?q=%23Monorepo" title="#Monorepo">#Monorepo</a> <a href="/search/result?q=%23React" title="#React">#React</a> <a href="/search/result?q=%23%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B" title="#软件工程">#软件工程</a><br /><br />总结：<br /><br />本文主张前端代码库应从"水平分层"（按 components/hooks/utils 技术类型划分）转向"垂直切片"（按业务域/功能域组织）。作者以 Sentry 代码库十年演进为例，指出水平分层会导致代码分散、认知负荷高、耦合混乱；而垂直组织将同一业务域的组件、工具、类型内聚到一起，配合 Monorepo 的显式边界（exports/eslint-plugin-boundaries），能显著提升可维护性。虽然确定正确的垂直划分需要更多团队沟通，但这是支撑代码库长期演进的必要投资。<br /><br />文章要点：<br /><br />- 水平分层的隐患：把代码按 components / hooks / utils / types 分类虽然上手简单，但随着项目膨胀，同一业务逻辑会被拆得七零八落——比如 PageFilters 的组件、类型、工具函数散落在三个目录，改一个小需求要跳来跳去， cognitive load 直接拉满<br />- 垂直切片的核心思想：不按"技术类型"而按"业务域"分组，把同一个功能域（如 dashboard、profiling、billing）相关的组件、Hook、工具、类型全部收进一个目录；就像当年我们把 HTML/CSS/JS 从三层文件合并成组件一样，这次是更高维度的"关注点内聚"<br />- 与团队结构天然对齐：现代产品团队通常是端到端的功能团队（dashboard 团队、replay 团队），垂直代码结构让 CODEOWNERS 和包边界直接对应团队职责，谁负责什么一目了然<br />- 解决跨域复用焦虑：不是所有代码都严格属于某个页面，像 PageFilters 这种被多页面使用的通用能力，完全可以作为独立垂直域存在；关键是按"逻辑关联"而非"物理位置"来划分<br />- 用边界守护架构：垂直化后还需降低耦合，推荐通过 Monorepo + package.json#exports 显式暴露公共 API，或借助 eslint-plugin-boundaries 禁止深路径导入，把"私有实现"真正保护起来<br />- 没有银弹，但值得投入：确定合理的垂直域确实比"丢进 utils"更难，也可能出现不同团队重复造轮子；但作者认为这恰恰促进了团队沟通，而沟通本就是软件工程最难也最重要的部分<br /><br />文章URL：<br /><br /><a href="https://tkdodo.eu/blog/the-vertical-codebase" target="_blank" rel="noopener" title="https://tkdodo.eu/blog/the-vertical-codebase">https://tkdodo.eu/blog/the-vertical-codebase</a><a class="tgme_widget_message_link_preview" href="https://tkdodo.eu/blog/the-vertical-codebase" target="_blank" rel="noopener" title="Let's take a look at why the common, horizontal code structure is not ideal, where it breaks down, and what we can do about it."> <div class="link_preview_site_name accent_color">tkdodo.eu</div> <img class="link_preview_image" alt="The Vertical Codebase" src="/static/https://cdn4.telesco.pe/file/UQNHQ5CBOo9YPc282-wjXkZj4PZ5DB5zFN6AcdBCGzJE5sJnuaw-V2V6sKibIvd5vfa9ekRtzuXoI6OnOZ_k1DF5YFoVfMgJHKVvA63WGg59BKOYzxTqmJaAxqyMw3QUQzlh3zNnw-BVDfmzabcFfGTp6KoV8nnXsMcAzd22mQ1iQg3o9vmfA9Scfo5p3viArCt5tGzxf-n2LhFYLOFxTKAPQtqhrcCjrFgB_maNEZlyJsUk_23V0odEQqqA-gZltg6z0v0kM7ke4letXnHXh4H8E2GYkTFJeFigVwwOpDsOhjT3Uq5wsaF5jXy-cAm6b1bXPEjfKWYiK3s8IC41Yg.jpg" width="1200" height="630" loading="eager" /> <div class="link_preview_title">The Vertical Codebase</div> <div class="link_preview_description">Let's take a look at why the common, horizontal code structure is not ideal, where it breaks down, and what we can do about it.</div> </a>