技术 · 设计 · 生活https://xiaoao-blog-firefly.pages.dev/Firefly6.15.6https://github.com/CuteLeaf/Firefly2026年8月7日 00:37:38https://xiaoao-blog-firefly.pages.dev/posts/full-stack-developer-portfolio-intro/https://xiaoao-blog-firefly.pages.dev/posts/full-stack-developer-portfolio-intro/一份不堆关键词的自我介绍：我如何从需求、UI、前后端到部署，独立完成一个可运行、可维护的 Web 产品。Sun, 19 Jul 2026 00:00:00 GMT<section><h2>我能解决什么问题<a href="#我能解决什么问题"><span>#</span></a></h2><p>我希望应聘的是一份需要独立完成前后端开发、网页建设和 UI 设计的工作。相比只列出会用哪些框架，我更愿意用这个博客证明：我能把一个想法拆成页面、数据、接口和部署方案，并把它真正交付。</p><p>这个站点不是静态模板。它包含 React 服务端渲染、内容管理、富文本编辑、身份认证、评论、搜索、缓存、媒体管理和后台控制台，运行在 Cloudflare Workers、D1、KV 与 R2 之上。</p></section> <section><h2>我的工作方式<a href="#我的工作方式"><span>#</span></a></h2><ul> <li>先明确用户目标与核心流程，再确定信息架构和页面层级。</li> <li>建立可复用的视觉规范，让颜色、字体、间距和组件保持一致。</li> <li>把业务逻辑、数据访问和界面分层，避免功能增长后代码失控。</li> <li>通过类型检查、自动化测试和真实浏览器验收保证交付质量。</li> </ul></section> <section><h2>这个博客证明了什么<a href="#这个博客证明了什么"><span>#</span></a></h2><p>前端方面，我能处理响应式布局、主题切换、交互状态、表单、富文本和可访问性；后端方面，我能设计 API、数据库模型、权限中间件、缓存和异步任务；工程方面，我会考虑错误处理、日志、测试、配置和上线后的维护成本。</p><p>后续文章会继续拆解这个项目的架构、UI 设计和数据层实现。这里展示的不是练习题，而是一套可以继续迭代的真实产品。</p></section>https://xiaoao-blog-firefly.pages.dev/posts/full-stack-project-quality-checklist/https://xiaoao-blog-firefly.pages.dev/posts/full-stack-project-quality-checklist/类型、错误、测试、日志、缓存与部署不是收尾工作，而是独立交付软件时必须完成的产品能力。Wed, 22 Jul 2026 00:00:00 GMT<section><h2>功能完成不等于项目完成<a href="#功能完成不等于项目完成"><span>#</span></a></h2><p>一个页面在本机打开，只能证明 happy path 暂时可用。真正的交付还要面对非法输入、网络失败、重复请求、权限差异、数据迁移和上线后的故障定位。独立开发意味着这些问题也必须由我负责。</p></section> <section><h2>类型与边界<a href="#类型与边界"><span>#</span></a></h2><p>项目使用 TypeScript 与 Zod 同时约束编译期和运行时数据。API 输入先校验，服务层使用 Result 返回可预期业务错误，数据库访问集中在 data 层。这样能让错误尽早暴露，也能避免界面、业务和 SQL 互相渗透。</p></section> <section><h2>测试策略<a href="#测试策略"><span>#</span></a></h2><ul> <li>工具函数使用单元测试覆盖边界条件。</li> <li>文章、标签、评论等核心流程使用 D1 集成测试。</li> <li>发布前运行类型检查、lint、格式检查和生产构建。</li> <li>关键页面进行桌面与移动端浏览器验收。</li> </ul></section> <section><h2>可观测性与性能<a href="#可观测性与性能"><span>#</span></a></h2><p>结构化 JSON 日志记录错误类型和上下文，便于在 Workers Observability 中搜索。缓存采用 CDN、KV、D1 多层策略，并通过版本化 key 处理失效。内容发布时预生成公开快照，将高亮等计算从读取链路移到写入链路。</p></section> <section><h2>上线前检查清单<a href="#上线前检查清单"><span>#</span></a></h2><ol> <li>环境变量是否完整且没有把密钥打进客户端包。</li> <li>数据库迁移是否可重复执行并有备份与回滚方案。</li> <li>错误页、空状态、权限拒绝和限流反馈是否可理解。</li> <li>SEO、站点地图、RSS、响应式和基础可访问性是否通过检查。</li> </ol></section> <section><h2>最后<a href="#最后"><span>#</span></a></h2><p>我理解的独立开发，不是一个人写完所有代码，而是能对完整结果负责：知道哪里可能坏、如何验证、如何观察，以及出现问题时如何恢复。</p></section>https://xiaoao-blog-firefly.pages.dev/posts/blog-ui-design-seven-decisions/https://xiaoao-blog-firefly.pages.dev/posts/blog-ui-design-seven-decisions/从视觉层级、排版、响应式到交互反馈，说明如何让一个内容型网站既有审美又真正好用。Tue, 21 Jul 2026 00:00:00 GMT<section><h2>设计目标先于装饰<a href="#设计目标先于装饰"><span>#</span></a></h2><p>博客的核心任务是阅读和发现内容，所以视觉设计不能抢走文章本身的注意力。我把目标定为：信息层级清楚、长文阅读舒适、移动端操作自然，同时保留足够鲜明的个人气质。</p></section> <section><h2>七个具体决定<a href="#七个具体决定"><span>#</span></a></h2><ol> <li>限制正文宽度和行长，降低长时间阅读的视线移动成本。</li> <li>用字体大小、字重和留白建立层级，而不是依赖大量边框。</li> <li>同时设计浅色与深色主题，并确保颜色语义在两种主题中一致。</li> <li>把按钮的 hover、focus、disabled 和 loading 当作完整组件状态处理。</li> <li>移动端优先保留主要动作，把次要操作收进菜单或折叠区域。</li> <li>为空数据、加载、失败和成功分别设计明确反馈。</li> <li>使用统一的设计 token 管理颜色、圆角、阴影和间距，避免页面各自发挥。</li> </ol></section> <section><h2>功能性如何被验证<a href="#功能性如何被验证"><span>#</span></a></h2><p>审美判断之外，我会检查键盘导航、焦点可见性、文字对比度、点击区域和不同宽度下的布局。真实浏览器测试能发现只看代码看不到的问题，例如标题换行、弹层遮挡、滚动位置和触摸设备上的交互冲突。</p></section> <section><h2>设计与开发一体化的优势<a href="#设计与开发一体化的优势"><span>#</span></a></h2><p>当同一个人理解产品目标、设计约束和实现成本时，可以更快找到兼顾效果与维护性的方案。组件不是截图的翻译，而是可复用、可扩展、能覆盖真实状态的产品单元。</p></section>https://xiaoao-blog-firefly.pages.dev/posts/cloudflare-workers-full-stack-blog-architecture/https://xiaoao-blog-firefly.pages.dev/posts/cloudflare-workers-full-stack-blog-architecture/从 SSR、API、D1 数据库到 KV 缓存与 R2 媒体存储，拆解一个边缘全栈项目的架构选择。Mon, 20 Jul 2026 00:00:00 GMT<section><h2>为什么选择边缘全栈<a href="#为什么选择边缘全栈"><span>#</span></a></h2><p>个人博客看似简单，但一旦加入后台、登录、评论、搜索和图片管理，就变成了一个完整 Web 产品。我选择 Cloudflare Workers 作为运行环境，是因为它能让页面渲染、API 和数据服务靠近用户，同时减少传统服务器的运维负担。</p></section> <section><h2>系统分层<a href="#系统分层"><span>#</span></a></h2><p>页面层使用 TanStack Start 与 React 19 负责 SSR、路由和交互；Hono 承担 API 网关；业务逻辑放在 service 层；Drizzle ORM 负责类型安全的数据访问；D1 保存文章、标签、评论和配置。KV 用于版本化缓存，R2 用于媒体文件。</p><p>功能模块按照 api、data、service、schema、components 和 workflows 拆分。data 层只处理数据库查询，service 层编排业务规则，UI 不直接依赖底层存储。这种边界让测试、替换实现和定位故障都更容易。</p></section> <section><h2>一次文章请求如何完成<a href="#一次文章请求如何完成"><span>#</span></a></h2><ol> <li>路由根据 slug 请求文章详情。</li> <li>服务层先读取版本化 KV 缓存，未命中时查询 D1。</li> <li>内容经过代码高亮和目录生成后返回 SSR 页面。</li> <li>页面设置缓存与 SEO 元数据，并在客户端完成交互增强。</li> </ol></section> <section><h2>我特别处理的工程问题<a href="#我特别处理的工程问题"><span>#</span></a></h2><p>服务函数使用 Result 类型表达可预期错误，调用方必须穷举错误原因；全局中间件记录结构化 JSON 日志；发布流程生成公开内容快照，避免每次访问重复执行昂贵转换；集成测试运行在 Cloudflare Workers 测试池中，使测试环境更接近生产环境。</p></section> <section><h2>结论<a href="#结论"><span>#</span></a></h2><p>技术选型的价值不在于新，而在于边界是否清晰、部署是否稳定、维护是否可控。这套架构让我能独立完成从数据库到用户界面的整条链路，也能在需求增长时继续演进。</p></section>