低卡饮食第300天，体重秤上的数字和腰围数据终于稳定在了一个让我能心平气和打开电脑写代码的区间。这他妈比搞定一个高并发爬虫还难。去年这时候，我还在为团队里三个程序员因为一个API接口的字段命名吵到要动手而血压飙升，现在每天最大的冲突是纠结晚餐的鸡胸肉该用黑胡椒还是迷迭香。这种对身体的绝对掌控，意外地让我找回了二十岁刚学编程时的那种感觉——你知道每一个变量在内存里的位置，知道每一行代码执行后的结果，那种确定性让人上瘾。
今天把项目博客的数据库表结构又重构了一遍。这玩意儿从2019年那个混乱的“客户需求管理表”演化过来，简直是我个人状态的缩影。最早那张表，字段多得吓人，client_name, client_phone, project_type, expected_delivery_date, actual_delivery_date, payment_status, developer_assigned, qa_status… 还有一堆is_deleted, created_at之类的元数据。当时觉得专业，现在看就是屎山雏形。为了应付那些狗屁倒灶的定制需求，表之间关联复杂得像蜘蛛网，一个简单的“项目进度查询”要join五张表，速度慢得让人想砸键盘。那会儿的思维就是“堆功能”，和当时胡吃海塞把自己吃到脂肪肝一个德行。
现在的结构，清爽得我自己都感动。核心就三张表。`articles` 表，id, slug（用于SEO友好的URL）, title, raw_content（存原始Markdown）, rendered_html, status（draft/published/archived）, category_id, view_count, created_at, updated_at。没了。`categories` 表更简单，id, name, slug, description。`tags` 和 `article_tags` 做多对多关联，为了以后灵活。所有“管理”性质的东西，比如文章历史版本、草稿自动保存，我全用时间戳和状态字段来逻辑实现，或者准备扔到像Redis这样的缓存里，绝对不再污染主表。
这种极简主义的背后，是这300天饮食控制给我的最大启示：冗余即是负担。以前做项目，总想着“万一以后需要呢”，拼命加字段、加配置项。结果就是系统臃肿，维护成本爆炸，就像身体里多余的脂肪，不仅没用，还消耗你的能量，让你反应迟钝。现在我做任何设计，先问“现在是否100%必要？” 如果答案是否定的，就坚决砍掉。`articles`表里连个`author_id`都没留，因为这个博客就我一个人写。为了一个虚无缥缈的“多作者功能”预留字段？滚蛋吧。
技术栈也彻底回归原始。不用WordPress，不用那些臃肿的CMS，就自己用Go写个简单的后端，模板渲染。前端？几乎裸的HTML/CSS，加一点点vanilla JavaScript处理交互。加载速度飞快，没有依赖，没有安全漏洞，就像吃干净的原型食物，成分明确，没有那些看不懂的添加剂。SEO？把slug和meta description处理好，网站结构弄清晰，比堆砌那些华而不实的“SEO插件”管用多了。这感觉，就像你终于不用再计算那些复杂的卡路里，身体自然告诉你它需要什么。
团队解散后，我一个人对着电脑的时间反而更长了，但焦虑感却降到了最低。因为我知道，每一个字节的数据，都在我设计的这个简洁结构里有序流动；每一口吃进去的食物，都在为我接下来的三小时编码提供稳定能量。这种对系统和身体的双重掌控，是前几年在管理泥潭里挣扎时完全无法想象的。那时候，你掌控不了客户朝令夕改的需求，掌控不了程序员突然离职的情绪，甚至掌控不了自己因为应酬而不断飙升的尿酸。
现在，晚上十点，处理完最后一条数据库索引优化，关掉电脑。冰箱里拿出准备好的明日午餐：精确到克的糙米、西兰花和煎牛排。看着这些，比看银行账户里那些随着项目起伏的数字踏实多了。代码会过时，技术会迭代，但一个能高效运转、不出毛病的身体，才是跑赢所有周期的底层基础设施。这个博客项目，就是这个新基础设施上的第一个应用。它不宏伟，但每一个字节，都透着掌控感。
