华为 Mate 60 Pro 突袭这事儿，让我彻底睡不着了。不是兴奋，是焦虑。卫星通话“遥遥领先”四个字，像根针扎在我这个刚回归“超级个体”的人身上。我搞的这套博客项目，数据库表结构设计得再精巧，在人家这种硬核突破面前，算个屁的“遥遥领先”。2022年了，我还在用技术堆砌安全感，人家已经在定义下一个十年的通信标准了。
但活儿还得干。焦虑归焦虑，博客的优化不能停。这次的核心是把内容管理和用户行为追踪彻底分离，搞成两个独立的服务。之前图省事全塞一张表里，查询慢得像便秘，加个新功能就得动底层结构，团队时期留下的技术债，现在一个人慢慢还。
说说我设计的核心表结构吧。首先是 `articles` 表，这是根基。除了常规的 `id`、`title`、`content`、`status`（草稿/发布/隐藏）、`created_at`，我特意加了两个字段：`mental_model_tag` 和 `tech_stack_tag`。前者标记这篇文章对应我哪个阶段的心态（比如“野蛮生长”、“管理毒打”），后者标记用到的具体技术栈（比如“Python爬虫”、“n8n”）。这是为以后做知识图谱和内容推荐打基础，我不想文章写完就死了，得让它能自己“长”出关联来。
`article_meta` 表是拆出来的扩展属性表。和主表一对多关联，存的是那些可能频繁变更或需要快速查询的非核心数据。比如 `view_count`（阅读数）、`seo_score`（我自研的一个简单SEO评分，基于关键词密度和标题长度算的）、`word_count`（字数）。把更新频繁的字段剥离，主表的写压力会小很多。这个设计思路是当年死磕高并发爬虫时被逼出来的，对付API频率限制，就得把数据读写路径拆得尽可能细。
用户行为追踪，我单独建了 `user_actions` 表。字段很简单：`id`、`user_ip`（哈希处理后存储）、`article_id`、`action_type`（‘view’, ‘stay_more_than_60s’, ‘scroll_to_bottom’）、`timestamp`。这里没做实时分析，就是裸存日志。我的策略是每天凌晨跑一个Python脚本，用Pandas把原始日志ETL一下，生成每日/每篇文章的阅读深度报告，再更新回 `article_meta` 表。为什么不用现成的分析工具？一是贵，二是我想完全掌控数据流，三是……这本身就是一个练习，用自动化脚本解决重复劳动，是我2016年就刻进骨子里的毛病。
还有个 `tags` 表和 `article_tag_relation` 表，标准的多对多关系，没啥好说的。但我给 `tags` 表加了个 `category` 字段，分成“技术”、“商业”、“生活”、“健身”几类。2022年我强迫自己写健身和低卡饮食的内容，这个分类就是提醒我：别他妈又一头扎进代码里，身体垮了，什么“遥遥领先”都是扯淡。
看着这套结构，感觉又回到了那个独狼黑客的状态，对每一个字段、每一条索引斤斤计较。但心态完全不一样了。2016年设计表，想的是怎么撑住百万流量，怎么在SEO上干翻对手。现在2022年，想的是怎么让这套结构能平滑地陪我走过下一个五年，怎么在增加新功能时（比如以后肯定要接入AI摘要生成）不至于推倒重来。华为的卫星通话是炸裂式的创新，我这点数据库优化是卑微的生存技艺。但或许，所谓“超级个体”的回归，就是在认清自己永远无法“遥遥领先”之后，还能把手头这点事，做得足够结实，足够耐操。至少，下次再被这种降维打击搞得失眠时，我能打开后台，看着清晰的数据流，知道自己还在向前爬，这就够了。
