在「快缩短网址」suo.run 的产品世界里，信息不是散乱的尘埃，而是可被精心编排的星辰。
当功能结构图像银河般铺陈出航道，信息结构图便为每一颗星命名、编组、赋义，使浩瀚不再令人迷失，而令人敬畏。

一、信息结构图：让对象自己说话
信息结构图不是页面地图，也不是交互脚本，它是一份“对象自述”。
它回答的问题是：若要完整描述一个事物，究竟需要哪些维度？
以微信好友为例——头像、昵称、备注、地区、签名、来源、标签、朋友圈可见性……这些字段共同构成了“好友”这一信息主体。它们不因出现在不同页面而分裂，也不因被不同功能调用而稀释；它们是同一颗钻石的不同切面，始终折射同一束光。



二、信息结构图的三重气质
1. 功能的“食材清单”
功能像厨师，信息像食材。再高超的厨艺，若无米之炊亦枉然。
“发送好友名片”之所以成立，是因为“好友”这一信息主体早已存在可被调用的字段。功能只是把这些字段按场景装盘。
2. 与页面、交互彻底解耦
页面是舞台，交互是舞步，信息是演员本身。
演员可以在不同舞台、不同灯光下登场，但角色属性不变。
3. 数据表的“基因图谱”
开发者在建表时，最怕的不是字段多，而是缺。
一份清晰的信息结构图，让后端工程师一眼读透对象的“基因”，从而优雅地写出 DDL，预留扩展位，避免后期返工。

三、为什么必须画信息结构图？
1. 为大脑减负
米勒定律告诉我们：短时记忆只能容纳 7±2 个组块。
当功能复杂到横跨数十个字段、多个对象时，单靠记忆绘制原型，无异于徒手搬运星辰。
信息结构图把“需要记住”变成“需要查阅”，让设计师把脑力留给体验与创意。
2. 为协作提效
在 suo.run，我们把信息结构图钉在 Figma 文件的最顶层。
UI 设计师据此排布信息层级，前端据此 mock 数据，后端据此建表，测试据此写断言。
一张图，四端同频，减少 30% 的沟通往返。
3. 为迭代留余地
今日不用的字段，明日可能长成新功能。
信息结构图让我们提前为“未来的可能性”埋点，而不污染当下的简洁。



四、绘制信息结构图的四步心法
1. 锁定主体
在「快缩短网址」的后台，若要做“链接分析”功能，需先回答：核心主体是谁？
——是“短链”。
2. 穷举字段，再无情删减
短链可被描述的字段有：原始长链、短链 key、创建者、创建时间、过期时间、访问次数、访问地域分布、设备分布、UTM 参数……
但并非全部进入 MVP。
对首期“链接分析”而言，原始长链、短链 key、创建者、创建时间、访问次数即够。其余字段放入“预留池”，待功能扩张时再唤醒。
3. 分组命名，建立语义层
把字段按“身份属性”“行为数据”“扩展配置”三层收纳，让阅读者一眼定位。
4. 与功能结构图对齐
功能结构图回答“做什么”，信息结构图回答“用什么做”。
两图叠合，即可快速推导：
· 哪些字段需在哪个页面出现；
· 哪些字段需做权限隔离；
· 哪些字段需实时计算，哪些可离线同步。

五、在 suo.run 的实践缩影
我们曾在 48 小时内上线“防红盾”功能：当目标链接被微信拦截时，系统自动切换备用域名。
功能虽小，却涉及“短链”“域名池”“告警日志”三个信息主体。
借助信息结构图，我们把“域名池”拆为：域名、启用状态、权重、健康检测时间、连续失败次数。
正是这 5 个字段，让后端仅用 2 张表、3 个接口便支撑了整套容灾逻辑。
上线当天，拦截率从 12% 降至 0.3%，而开发工时比预估节省 40%。

尾声
功能结构图让产品“跑得快”，信息结构图让产品“跑得远”。
在 suo.run，我们把每一次缩短，都视作一次信息的精炼；
把每一张信息结构图，都视作对未来复杂度的提前偿还。
愿你亦能在自己的星辰大海里，用信息结构图为每一束光命名，让产品既璀璨又恒久。