织梦CMS默认的织梦文章发布流程里，发布时间只能选“当前时刻”或手动填一个过去的发布时间点。想让文章在明天早上8点自动出现在前台，文章原生功能做不到。插件这不是织梦bug，是发布设计逻辑——dede把发布时间当作记录属性，而非触发条件。文章

我最早碰到这个问题是插件给一个本地美食号做内容排期。编辑每天下午集中写完稿子，织梦但希望分早中晚三个时段推送，发布模拟真人运营节奏。文章手动定闹钟去后台点发布，插件坚持了三天就放弃了。织梦后来找了个插件，发布才算把这事自动化。文章

插件到底改了什么

核心原理不复杂。dede的archives表里有个pubdate字段，存的是文章发布时间戳。前台列表页查询时用WHERE pubdate <= 当前时间来过滤。插件要做两件事：一是把未来时间的文章先存进数据库但标记为“未到发布时间”，二是让前台查询时自动跳过这些记录，等时间到了再放出来。

听起来简单，但dede的模板标签{ dede:arclist}底层SQL是写死的，不会自动加时间判断。插件通常通过两种方式介入：要么改arc.listview.class.php这类核心文件，要么用钩子函数在查询前修改SQL条件。前者兼容性差，升级dede容易冲突；后者干净，但要求插件作者对dede的sphinx或mysql查询链有足够了解。

我用的那个插件是在include/taglib/arclist.lib.php里加了一层判断：如果文章pubdate大于当前时间，就WHERE条件里排除掉。同时后台文章列表会显示“定时待发布”状态，编辑能一眼看到哪些稿子排着队。

实际用起来会遇到什么

第一个坑是缓存。dede默认开静态缓存，列表页生成后不会实时查数据库。插件如果只改SQL不改缓存策略，时间到了页面还是旧内容。解决办法是配合arclist的cacheid参数，把定时发布区的缓存时间设短，比如60秒。或者干脆关掉那块的缓存，用{ dede:arclist cacheid=''}。

第二个坑是批量操作。有次编辑一次性排了20篇稿子，结果插件只处理了前10篇。查了半天发现是limit参数和分页逻辑打架——插件在LIMIT之前就过滤了未来文章，导致实际返回数量不够。后来把过滤条件放到LIMIT之后才正常。

第三个坑最隐蔽：dede的pubdate用的是服务器时间戳，但有些虚拟主机时区设的是UTC。编辑在北京时间下午5点设“明早8点发布”，实际执行时差了8小时。插件本身没问题，是服务器环境埋的雷。检查php.ini里的date.timezone，改成Asia/Shanghai就解决了。

值不值得装

如果你只是偶尔手动发文章，没必要折腾。但如果是团队运营，编辑和发布分离，或者需要配合SEO做固定时间更新，这插件能省不少事。我见过一个站群运营者，用定时发布把50个站点的内容排期统一管理，每天自动错峰更新，搜索引擎抓取频率明显稳定了。

选插件时注意看它改的是核心文件还是走钩子。改核心文件的，dede升级后大概率要重新打补丁；走钩子的虽然少，但更安全。另外测试时别只看前台，后台的“待审核”“已发布”状态流转也要确认——有些插件只改了前台展示，后台状态没同步，编辑会以为文章丢了。

最后提醒一句：定时发布依赖服务器的计划任务（crontab）或者用户访问触发。如果站点流量极低，可能时间到了但没人访问首页，文章还是不会自动“出现”。这时候需要配一个cron定时刷新缓存，或者用插件自带的“强制发布”接口。别问我怎么知道的，都是踩过的坑。

(责任编辑：知识)