poxiaoxi博客设计资讯网站、社区、博客或内容型APP时，一篇文章往往不只有标题和正文。详情页上常见的浏览量、点赞、收藏、评论，以及后台使用的发布状态、置顶、推荐等信息，都属于文章系统需要考虑的数据。
不过这些数据并不都属于“文章自身属性”。例如文章有多少点赞可以作为统计值保存，但“当前用户有没有点赞”实际上属于用户与文章之间的关系。产品设计阶段先把这些概念区分清楚，后面的接口和数据库会简单很多。
文章最基础的内容字段
一篇文章最核心的属性通常包括：
文章ID，用于唯一识别内容。
标题。
正文。
摘要。
封面图片。
作者。
所属分类。
标签。
创建时间。
发布时间。
最后更新时间。
这些字段主要回答“这篇文章是什么”。对于普通博客、资讯网站和知识社区，这一组数据基本都会存在。
文章通常需要发布状态
内容后台一般不会只有“发布”和“未发布”两个状态。
常见状态包括草稿、待审核、已发布、定时发布、私密和已删除。如果是UGC社区，还可能增加审核中、审核拒绝、重新审核等状态。
比较推荐把“发布状态”和“审核状态”分开。因为一篇已经发布的内容，也可能由于举报或内容修改重新进入审核。
浏览量表示页面被查看次数
浏览量通常使用：
view_count
前台可能显示为“1256次浏览”或“1.2万阅读”。
真正设计时，需要先定义什么算一次浏览。同一个用户刷新10次是否全部统计，机器人访问是否排除，短时间重复访问是否去重，都需要根据产品规模决定。
小型内容产品可以先使用简单累计方式，数据规模增加后再加入用户、设备或时间窗口去重，没有必要一开始把浏览统计设计得过于复杂。
点赞要区分数量和状态
点赞通常至少涉及两个信息。
第一个是整篇文章的点赞总数：
like_count
第二个是当前用户是否点过赞：
is_liked
两者不是同一个字段。
like_count属于文章统计数据，而is_liked取决于当前登录用户。因此系统通常还需要保存用户和文章之间的点赞记录。
这样用户取消点赞时，系统才知道应该删除哪一条关系，而不是只修改一个总数字。
收藏和点赞最好分开
收藏常见字段是：
favorite_count
当前用户的收藏状态可以是：
is_favorited
点赞通常表达认可，收藏更多表示“以后还想看”。用户完全可能收藏文章但不点赞，因此两种行为最好独立设计。
如果产品包含“我的收藏”页面，还需要保留具体收藏关系，而不能只有文章的收藏总数。
评论至少有数量和开关
文章评论通常会涉及：
comment_count comment_status
comment_count表示已有多少评论，comment_status决定现在是否允许继续评论。
例如一篇文章已经有80条历史评论，运营人员后来关闭评论功能，这时评论数量仍然是80，但评论状态已经关闭。
具体评论内容通常作为独立数据保存，不会直接塞进文章记录中。
分享量不一定必须存在
有些内容产品会记录：
share_count
但需要明确这个数字代表什么。
网站通常只能知道用户点击了多少次站内分享按钮，却不一定知道链接最终有没有真正发送出去。如果用户直接复制浏览器地址分享，系统甚至可能完全不知道。
所以如果产品没有分享排行榜、推荐计算或运营统计需求，没有必要为了字段齐全强行增加分享量。
常见互动数据可以这样选
普通内容产品比较常见的统计字段包括：
view_count like_count favorite_count comment_count share_count
但不是每个产品都需要全部展示。
教程网站可能更重视浏览和收藏，社区内容更重视点赞和评论，新闻产品则可能主要展示阅读量。
字段应该跟产品实际行为有关，而不是别人有几个数字，自己的详情页也必须放几个。
后台还会有运营属性
内容运营通常还需要一些用户看不到，或者只在特定情况下展示的字段，例如：
是否置顶。
是否推荐。
是否允许评论。
文章来源。
发布时间。
下线时间。
审核人员。
删除原因。
如果产品有推荐系统，还可能存在推荐权重或热度分数。
“热门”这类状态不一定要人工维护，也可以根据近期浏览、点赞、评论和发布时间动态计算。
网页文章还可以增加SEO属性
如果文章除了APP内展示，还会生成公开网页，可以增加：
slug seo_title seo_description canonical_url og_image
这类字段主要服务搜索引擎和社交分享。
例如文章站内标题和搜索结果标题可以不同，分享时使用的封面图也可能与正文第一张图片不同。
如果内容完全存在于封闭APP中，没有公开Web页面，这部分通常可以省略。
时间字段不要只留一个
文章至少建议区分：
created_at published_at updated_at
因为“创建文章”“正式发布”和“最后编辑”可能发生在三个不同时间。
如果有定时发布，还可以增加：
scheduled_at
这种拆分以后做内容排序、展示更新时间和后台审计都会更方便。
哪些属于用户行为数据
下面这些信息虽然经常出现在文章接口里，但严格来说并不是文章自身属性：
is_liked is_favorited reading_progress has_reported
因为它们会随着当前用户变化。
同一篇文章，用户A可能已经点赞，用户B没有点赞，所以不能把is_liked=true永久保存到文章本身。
接口可以把这些信息一起返回给前端，但数据库层面最好仍然区分文章数据和用户关系。
基础版本可以先做哪些字段
如果刚开始设计一个内容产品，不需要一次建立几十个属性。基础版本可以先保留：
id title summary content cover_image author_id category_id status comment_status view_count like_count favorite_count comment_count created_at published_at updated_at
然后根据当前用户返回：
is_liked is_favorited
如果以后确实需要分享统计、置顶推荐、SEO或阅读进度，再逐步增加即可。
文章字段应该跟产品目标走
文章属性并不是越多越完整。每增加一个统计字段，后面往往还涉及记录规则、接口更新、后台展示和数据一致性。
设计时可以先问一句：这个字段以后具体用来做什么？如果只是为了详情页多显示一个数字，没有推荐、运营、用户反馈或个人管理价值，就可以暂时不做。
对于大多数内容产品，先把标题、正文、作者、时间、发布状态以及浏览、点赞、收藏、评论这几组基础数据设计清楚，已经足够支撑第一阶段使用。
精彩评论