企业官网建设流程全解析

1. 加字段前先想清楚：什么时候该动文章表，什么时候不该动

给Typecho文章表添加新字段，听起来不过是执行一条ALTER TABLE的事，但真正做二次开发时，你会发现要动的地方远不止数据库。以最经典的需求“文章浏览量”为例，你要面对的是：后台怎么写值、编辑时怎么回显、前台模板怎么读取、列表页能不能按这个字段排序、SQLite和MySQL的建表语句为什么不一样。每一环漏掉，都会出现“字段加了但功能没生效”的怪现象。

先说一个很容易混淆的前提。Typecho里通常说的“文章表”，并不是一张专门装文章的表，而是contents表。文章、独立页面、甚至部分内容聚合，都存放在这张表里，通过type字段区分：post代表文章，page代表独立页面。所以你执行ALTER TABLE时，修改的是整个站点的内容主干表，而不是一个单独的post表。

这张表常用的字段有这些：cid（内容ID）、title（标题）、slug（缩略名）、created（创建时间）、modified（修改时间）、type（内容类型）、status（发布状态）、text（正文内容）、order（排序）、authorId（作者ID）、password（密码保护）、commentsNum（评论数）、allowComment/allowPing/allowFeed（评论、引用、订阅开关）、template（模板）、parent（父级ID）。这些字段各有用途，新增字段一般加在这些已有字段后面，比如加在commentsNum旁边。

那什么时候不该动文章表？Typecho本身提供了“自定义字段”机制，写作页面最下方的“自定义字段”面板，本质是把数据存到metas表里，通过fields对象读取。如果只是给某几篇文章记一个简单的备注、来源链接，用原生自定义字段就够了，完全不用改表。真正需要给文章表加列的典型场景，是当你需要对这个字段做全表查询、排序、聚合统计时。比如按浏览量排热门文章、按某个评分字段筛选、在列表页直接输出某个结构化数据。自定义字段存储在metas表里，读取时还要额外拼查询，排序性能很差，远不如直接把字段做成表里的真实列来得干净。

我做过一个案例：客户要求首页展示“热门专题”，需要按文章表里新增的topic_sort字段做排序，同时后台文章编辑页要填写这个值。如果走自定义字段，列表页排序必须先把所有文章的字段读出来再在PHP里挨个比较，文章一多内存就扛不住。直接给typecho_contents表加一个整数列，一句ORDER BY topic_sort DESC就能搞定。这就是“该动文章表”的时候。

2. 动手加字段：SQL写法与在Typecho代码里执行建列的姿势

2.1 不同数据库的ALTER写法差异

Typecho官方支持MySQL、SQLite、PostgreSQL，不同数据库的加列语句写法差异很大，这点很多人容易忽视。MySQL是最常见的，语法也最宽松：

ALTER TABLE `typecho_contents` ADD `views` INT(10) UNSIGNED NOT NULL DEFAULT '0' COMMENT '文章浏览量' AFTER `commentsNum`;

这里我说一下几个参数的含义：INT(10)是整数类型，10只是显示宽度，不影响存储范围；UNSIGNED表示无符号整数，适合浏览量这种不可能是负数的字段；NOT NULL DEFAULT '0'保证旧文章在没有数据时也能读出确定的默认值；AFTER commentsNum表示字段添加在commentsNum之后，纯粹是为了数据库里看起来整齐，不影响功能。

SQLite不支持AFTER语法，也不支持COMMENT，写法必须简化：

ALTER TABLE `typecho_contents` ADD `views` INTEGER NOT NULL DEFAULT 0;

SQLite把整型统一叫INTEGER，加列时无法指定位置，新字段只能放在表末尾。如果用了AFTER，SQLite会直接报语法错误，这也是很多Typecho用户在本地用SQLite调试时，一执行MySQL的建表语句就白屏的原因。

PostgreSQL的写法又不一样，它用ADD COLUMN关键字：

ALTER TABLE typecho_contents ADD COLUMN views integer NOT NULL DEFAULT 0;

PostgreSQL的整型是integer，也不支持AFTER。所以跨数据库开发时，最稳妥的做法是先用Typecho_Db::get()判断当前使用的驱动，再选择对应的SQL，不要一个SQL走天下。

2.2 在Typecho代码里安全执行加列操作

实际项目里，很少会有人手动登录数据库执行SQL，更多的是把加列操作写进插件的activate()方法里，或者写成一个升级脚本，让代码自己完成。Typecho的插件激活方法要求是静态方法，数据库操作可以直接用全局数据库对象：

public static function activate() { $db = Typecho_Db::get(); $prefix = $db->getPrefix(); try { $row = $db->fetchRow($db->select()->from('table.contents')->limit(1)); if (!$row || !array_key_exists('views', $row)) { $db->query("ALTER TABLE `{$prefix}contents` ADD `views` INT(10) UNSIGNED NOT NULL DEFAULT '0'"); } } catch (Typecho_Db_Exception $e) { // 建表执行异常时需要处理，但不能直接抛出导致插件无法激活 return false; } }

这里有两个关键点。第一，table.contents是Typecho查询构造器里对typecho_contents表的标准化写法，它会自动替换成带前缀的实际表名，写死typecho_contents在改了表前缀的站点上会直接报错。第二，先用fetchRow获取一行数据，判断views字段是否已经存在，避免重复执行ALTER TABLE时报“字段已存在”的错误。

如果contents表里一条数据都没有，fetchRow会返回false或者空数组，所以if (!$row || !array_key_exists(...))这个判断不能省。还有一个更直接的办法，是干脆把加列操作包在try里，执行完了再判断一次字段是否存在：

$db->query("ALTER TABLE `{$prefix}contents` ADD `views` INT(10) UNSIGNED NOT NULL DEFAULT '0'");

但这种写法在重复执行时会把异常抛出来，插件激活界面就会出现红色报错信息。生产环境还是推荐先判断、再加列的写法。

2.3 加列之后要不要初始化旧数据

加完字段，最容易被忽视的是旧文章的数据。NOT NULL DEFAULT '0'会让所有已有文章的views自动变成0，但这不一定符合预期。比如你加的字段是文章类型article_type，默认值给article还是note，需要先想好。还有一种情况，你希望旧文章的某个字段从旧值迁移过来，比如把已经有浏览量插件的统计结果迁入新字段，那就需要在加列后写一条UPDATE语句，把旧数据刷进去。

迁移刷数有个常见坑：Typecho的contents表里同时有文章和页面，如果只针对文章刷数，一定要带上type='post'条件，否则会把独立页面也刷一遍。

3. 后台发布与编辑流程：新字段必须经过的三个处理点

3.1 write-post.php表单如何接入新字段

字段建好后，第一件事是让后台文章编辑页能输入这个字段。Typecho的后台文章编辑页面是/admin/write-post.php，这个文件里有很多表单控件，比如标题输入框、内容编辑区、自定义字段区。要加入新字段，直接在合适的表单区域加一个input标签就行：

<p> <label for="post-views">浏览量</label> <input type="text" name="views" id="post-views" value="<?php echo isset($post->views) ? htmlspecialchars($post->views) : '0'; ?>" /> </p>

这里我特意强调isset($post->views)的判断。因为新建文章时，$post对象里没有views这个属性，不做判断会直接报“Undefined index”或者输出空值。编辑旧文章时，$post->views来自数据库查询结果，Typecho的组件对象会把查询出的字段自动映射成对象属性，所以直接用就行。

注意htmlspecialchars这一步不能省。后台表单回显时，如果字段值是用户之前输入的一段文本，不转义的话，浏览器可能把引号、尖括号解析成HTML结构，轻则布局错乱，重则构成XSS风险。这一点在给文章表加“原文链接”“跳转URL”这类字段时尤其重要。

3.2 Edit.php的publish()如何接收并写入

表单提交后，数据要送到后台处理逻辑里。Typecho文章保存的核心逻辑在/var/Widget/Contents/Edit.php，其中的publish()方法负责接收表单数据、组装$contents数组，然后调用insert()或update()写入数据库。

默认情况下，publish()方法会通过$this->request->from('title', 'slug', 'text', ...)这样的方式从请求中提取固定字段。新字段views不在这个提取列表里，所以就算表单里有name="views"的输入框，提交后也不会被写入。这就是很多人遇到的“字段加了、表单也填了、数据库里永远是默认值”的根源。

需要在publish()方法里找到数据组装的位置，把views加进去：

$contents = $this->request->from('title', 'slug', 'text', 'password', 'template', 'tags', 'category', 'allowComment', 'allowPing', 'allowFeed', 'trackback', 'views'); // 或者单独处理，做一下类型转换 if ($this->request->get('views') !== null) { $contents['views'] = intval($this->request->get('views')); }

第一种方式最直观，把views加进from()的字段列表里，它就会被自动提取到$contents数组。第二种方式更精细，可以在写入前做类型转换。我强烈建议对数值型字段做intval()处理，因为表单提交过来的值永远是字符串，哪怕你输入的是“123”，实际上拿到的是"123"。直接写入字符串到一个整型列，MySQL通常能自动转换，但SQLite严格模式下可能出问题，还是老老实实转成整数更稳妥。

3.3 编辑回显：为什么不用额外查询

保存完之后，用户可能要去编辑页继续修改。这里很多人会踩一个惯性误区：觉得新字段是我自己加的，后台编辑页读不出来，是不是还得写SQL查询？完全不用。Typecho的Widget_Contents_Edit在编辑文章时，会根据cid把整行记录查出来，查询用的是SELECT *，新字段天然就在结果集里。所以只要你在write-post.php的表单里写了$post->views，它就能正常显示。

这里唯一要注意的是，编辑页的数据来源和数据库表字段是绑定的。如果数据库里没有views列，$post->views会返回NULL，前端代码要做空值判断。这也是为什么我建议字段要设置NOT NULL DEFAULT默认值，能省掉一大堆空值判断的逻辑。

4. 前台查询与模板调用：字段从数据库到浏览器的完整链路

4.1 Archive查询对象如何自动带上新列

后台能写能读之后，前台的活就简单多了。Typecho的前台文章查询主要在/var/Widget/Archive.php，这个组件充当了“当前页面数据源”的角色。无论你打开的是文章页、列表页还是独立页面，Typecho都会用Archive去查询当前需要的内容。查询默认是SELECT *，所以只要字段加到了contents表里，Archive查询结果就会自动包含它。

这意味着模板里直接调用$this->views就能拿到新增字段的值。注意这里有个容易混淆的地方：Typecho模板经常用$this->fields->views访问自定义字段，这个fields对象背后的数据在metas表，和contents表的真实列是两套数据源。如果你用$this->views读不出值，先确认字段是真实加到了表里，还是存在自定义字段里。两种存储方式的读取方式不一样。

4.2 模板里的正确调用写法

在主题模板中，输出一个新字段可以用下面几种方式：

// 文章页、独立页面 <?php echo $this->views; ?> // 列表循环里（如首页文章列表） <?php while ($this->next()): ?> <span>浏览量：<?php echo $this->views; ?></span> <?php endwhile; ?>

$this->views在Typecho模板里会经过__get魔术方法，最终从当前文章的查询结果里取值。如果你的环境是Typecho 1.0以上版本，这个机制一直有效。输出时如果字段是纯文本（比如“来源链接”），建议加htmlspecialchars再输出：

<?php echo htmlspecialchars($this->source); ?>

因为文章内容的标题、摘要都有可能有各种转义机制，新字段未必被纳入安全过滤。自己加的字段，输出安全要自己负责。

4.3 按新字段排序：这才是加列的真香场景

给文章表加真实列之后，最大的好处是可以直接在数据库层排序。比如按浏览量排热门文章，后台查询可以这么写：

$db = Typecho_Db::get(); $query = $db->select()->from('table.contents') ->where('type = ?', 'post') ->where('status = ?', 'publish') ->order('views', 'DESC') ->limit(10); $hotPosts = $db->fetchAll($query);

order('views', 'DESC')直接就能按views字段倒序排列，数据库执行ORDER BY比自己写PHP循环排序高效得多。如果你用自定义字段存浏览量，这一步就做不了了，因为metas表里的值是键值对，不构成可排序的列。

还有一种常见的查询需求是筛选，比如只显示“已推荐”的文章。假设你加了一个is_featured字段，默认值0，推荐设置为1，那么查询时就是：

->where('is_featured = ?', 1)

这就是真实列的好处：可以做条件过滤、聚合统计、连接查询。自定义字段在这类场景里的性能表现，基本只能勉强应付小站点。

5. 漏改某个位置会出现什么怪现象：排查对照表

5.1 字段“写不进去”的典型排查

我见过最多的问题是：表单加了、字段也建了，但在后台填完保存后，回到编辑页发现值还是空的。这种问题一般出在publish()方法没有接收新字段，也就是3.2节里说的from()列表没加views。排查方法很简单，在publish()方法里临时加一句error_log(json_encode($contents));，保存一次文章，看日志里到底有没有views这个键。没有，就说明请求参数没进组装数组；有，就去查数据库写入环节。

还有一种情况是后台表单报错，保存文章时提示某个字段不存在。这是因为$contents数组里带上了views，但数据库里还没来得及加这个列。所以顺序很重要：先加数据库列，再改后台接收逻辑。很多人一上来就改Edit.php，结果数据库还没执行ALTER TABLE，保存时自然报错。

5.2 前台“读不出来”的三种闹鬼情况

最诡异的问题往往是：数据库里有值，后台也能看到，前台就是输出空白。我总结过三种常见情况。

第一种，模板里把$this->views和$this->fields->views搞混了。上面说过，一个是真实列，一个是自定义字段，写错了自然读不到。

第二种，文章列表页循环里没有用$this->next()。Typecho列表模板必须先用next()定位到当前文章，才能通过$this取到该篇字段。如果在循环外直接用$this->views，取到的是整个Archive对象，不会是一篇具体的文章。

第三种，不是读不出来，而是被主题自带的字段缓存干扰了。有些Typecho主题或插件会给文章查询结果做静态缓存，加列之后缓存没刷新，前台一直读到旧数据。这种情况需要清掉Typecho缓存目录（通常是/usr/cache）里的缓存文件，或者到插件设置里清一次缓存。

5.3 改表改文件之后要不要清缓存的个人经验

说到缓存，我就多分享一个自己的操作习惯。Typecho本身有/usr/cache缓存目录，部分缓存插件还会在数据库里建表存缓存内容。每次执行完ALTER TABLE或者修改Edit.php、write-post.php之后，我都会手动去后台打开一次“控制台”，再访问一次前台页面，确保触发缓存重建。如果页面没变化，就删掉/usr/cache下的文件再试。

另外，修改PHP文件本身一般不用清缓存，但要留意是不是开了PHP的opcache扩展，而且opcache.validate_timestamps被禁用了。这种情况下，你改了Edit.php，PHP进程还在用旧文件，怎么测都不会生效。检查办法是在改完文件后重启一下PHP-FPM，或者等opcache自带的缓存过期时间过了再测。这个坑和Typecho无关，但做二次开发时最容易撞上。

还有一个老生常谈但我还是要提醒的：给contents表加字段时，千万不要用order、group、rank这类数据库保留关键字作为字段名。order字段在Typecho表里已经是保留用法了，你再加一个同名或类似语义的字段，查询时很容易出现SQL语法错误。我自己习惯给扩展字段加一个统一前缀，比如ext_views、ext_source，既能防关键字，又能一眼看出哪些字段是后来加的。

回到最开始的问题，给Typecho文章表添加新字段，核心其实就三步：数据库里建列、后台写入逻辑接收、前台模板读取。这三步只要按顺序处理，再顺手处理好类型转换和空值判断，大部分需求都能顺畅跑起来。如果你只是给某一个字段做排序，到这一步就够了，后面那些缓存和关键字问题属于锦上添花的避坑经验，遇到了再回来翻翻也来得及。