织梦二次开发入门：如何修改模板并保留核心功能

织梦（DedeCMS）站点的二次开发，常见工作不是重写整套系统，而是在现有内容模型、栏目结构和后台管理能力上调整页面：改版首页、增加文章卡片、调整详情页信息、让列表增加筛选提示，或把页面样式与品牌规范统一起来。对于这类需求，模板通常是最合适的入口。

模板开发看起来只是改 HTML，但页面内容往往由模板标签、栏目配置、字段数据、生成机制和静态文件共同组成。若直接改系统核心文件、用模板拼出一套平行的内容逻辑，短期可能能显示，之后却容易遇到更新困难、数据不一致、后台功能失效或安全风险。本文从维护现有站点的角度，介绍如何识别模板、做小步修改、验证结果并保留核心功能。

一、先判断：模板修改是否适合当前需求

以下工作通常适合优先修改模板：

• 调整页面结构、颜色、间距、字体和响应式布局。
• 在首页或栏目页展示已有文章、栏目、图片等内容。
• 调整文章详情页中标题、发布时间、作者、正文等现有字段的位置。
• 改动导航、面包屑、分页按钮的呈现方式，但不改变其数据来源和基本行为。
• 利用后台已经配置好的栏目、内容模型和字段，增加展示区块。

如果需求涉及新的数据关系、复杂筛选、用户权限、订单流程、支付、文件处理，或需要调用外部服务，就不能仅靠模板解决。应先确认站点使用的织梦版本、已有插件和运行环境，再决定是否通过后台配置、独立扩展或受控的程序开发实现。不要把业务逻辑塞进模板，也不要为了改页面而直接修改系统底层文件。

还要考虑项目的维护状态。织梦是历史较久的内容管理系统，不同站点可能使用不同版本、补丁和第三方扩展；不能仅凭“织梦”两个字推断其目录结构、标签能力或安全状态。维护前应查明实际版本与定制情况。若站点仍对公网开放，应安排安全审查、备份和更新评估；模板修改本身不能修复系统漏洞，也不能替代权限、补丁和服务器层面的安全措施。

二、动手前先保护现有站点

1. 确认站点使用的版本和模板目录

先在后台查看系统版本、当前默认模板风格和各栏目的模板设置。织梦常见模板目录形如 /templets/风格名/，例如 /templets/default/，但实际目录名、部署路径及模板分配方式可能已经被站点维护者改过。

不要只在目录里看到一个名为 default 的文件夹，就认定全站都使用它。首页、列表页、文章页和单独栏目可能分别指定了模板；同一个模板也可能被多个栏目共用。修改前，可以在后台查看相关栏目设置，或在页面源码、生成文件和服务器配置中交叉确认。若无法确定，不要通过批量替换来“试试看”。

2. 备份文件和数据库

至少备份准备修改的模板文件，以及站点数据库。若可能影响页面生成、栏目设置或内容字段，也应保留完整站点备份。建议先在本地或测试环境操作，确认无误后再发布。正式环境中修改前，记录文件原路径、修改时间和原始版本；不要把唯一一份备份放在可被公网直接访问的位置。

3. 找出模板依赖

同一页面可能由多个模板片段组合而成，例如头部、导航、主体和底部。查看目标模板中是否包含其他文件、模板标签或站点自定义代码。先理解它们的作用，再决定是否需要修改。不要删除看起来“暂时没有显示”的标签：它可能负责动态导航、分页、统计或其他页面功能。

三、认识模板标签：数据由谁提供，模板负责怎么展示

织梦模板通常通过花括号形式的标签调用系统或内容数据。一个重要原则是：模板标签的职责主要是组织展示，不等同于任意 PHP 程序。标签的可用名称、参数和解析细节会因版本、插件及站点定制而异，不能将某个站点里的示例直接当作所有版本的规范。

下面是常见的标签用法示意。运行前请在自己的站点中确认相应标签支持情况、模板文件格式和栏目数据是否存在：

<h1>{dede:field name='title'/}</h1>
<p class="site-name">{dede:global.cfg_webname/}</p>

{dede:field name='title'/} 常用于输出当前内容或页面环境中的字段，{dede:global.cfg_webname/} 常用于读取网站全局配置中的站点名称。标签具体可用的上下文和字段，以当前站点的系统版本、模板环境及已有页面为准。

展示文章列表时，常见做法是使用 arclist 标签，再通过字段标记输出标题和链接：

<ul class="article-list">
  {dede:arclist row='5' titlelen='60' orderby='pubdate'}
    <li>
      <a href="[field:arcurl/]">[field:title/]</a>
    </li>
  {/dede:arclist}
</ul>

这个示例的目标是列出内容，并展示标题和链接。row、titlelen、orderby 是该标签中常见的参数写法；参数能否按预期工作，取决于当前版本的标签实现和站点配置。不要据此推断所有标签都接受相同参数，也不要假设这些参数存在一个适用于所有版本的统一最大值。需要更多条目、不同排序或筛选条件时，应查阅该版本随附的文档或核对已有同类模板，并在测试环境验证。

列表模板里通常用 [field:字段名/] 形式输出循环记录的字段，当前页面上下文则可能使用 {dede:field name='字段名'/}。两种写法所处的解析环境不同，不能随意互换。若将列表字段标记放在循环之外，或将当前页面字段误放进循环，可能出现空值、内容重复或显示错位。

四、按页面类型逐步修改

1. 修改首页：先保留原有区块，再替换呈现方式

首页通常承担栏目入口、最新内容和站点导航等职责。建议先复制原模板形成一个可回退版本，再针对单个区块改版。例如，为已有文章列表增加标题和描述性结构，而不改文章数据来源：

<section class="home-news" aria-labelledby="home-news-title">
  <h2 id="home-news-title">最新内容</h2>
  <ul>
    {dede:arclist row='6' titlelen='60' orderby='pubdate'}
      <li>
        <a href="[field:arcurl/]">[field:title/]</a>
      </li>
    {/dede:arclist}
  </ul>
</section>

这里增加的是 HTML 结构和辅助标题，列表仍由原有内容系统生成。若还要显示摘要、缩略图或日期，应先确认当前列表标签是否能提供所需字段，以及字段在站点中的填充规则。不要假设字段一定存在；后台未录入的数据可能为空。

若栏目名称、链接或文章记录发生变化，先检查后台数据和栏目设置，不要为修复数据问题而在模板里写死一批网址。硬编码链接在栏目改名、迁移目录或调整站点域名后容易失效。

2. 修改栏目页：保留内容循环和分页功能

栏目列表页常由循环标签和分页标签共同完成。重做样式时，应保留原模板中的数据循环和分页输出逻辑，只调整外围 HTML、CSS 类和布局。不同站点的分页写法可能不同，下面用带说明的片段展示结构；其中分页标记应沿用原模板或该版本支持的标签，不宜凭空替换：

<section class="channel-content">
  <ul class="article-list">
    {dede:list pagesize='10'}
      <li>
        <a href="[field:arcurl/]">[field:title/]</a>
      </li>
    {/dede:list}
  </ul>

  <!-- 此处保留原模板中已经验证可用的分页输出代码 -->
</section>

pagesize 等参数的支持情况和含义应按当前站点版本核验；上例不是对所有部署都适用的强制配置。分页涉及列表查询与静态页面生成，若只留下第一页的 HTML 外壳而删掉原分页输出，页面可能看起来完整，却无法访问后续内容。修改后应检查第一页、第二页和没有内容时的表现。

如果列表要按分类、日期或自定义字段过滤，需要先明确筛选规则由谁执行。模板参数并不自动等于安全、完整的查询接口；复杂查询应使用站点已有、经过验证的功能，不要把用户提交的字符串直接拼进 SQL 或模板标签参数。

3. 修改详情页：保留正文与站点已有功能

文章详情模板常显示标题、发布时间、正文和相关链接。页面主体可围绕这些已有数据重新布局，例如：

<article class="article-detail">
  <header class="article-header">
    <h1>{dede:field name='title'/}</h1>
    <p class="article-meta">
      <time>{dede:field name='pubdate' function="GetDateTimeMK(@me)"/}</time>
    </p>
  </header>

  <div class="article-body">
    {dede:field name='body'/}
  </div>
</article>

日期格式化写法可能受版本和模板解析规则影响。正文中的 body 字段也应以当前详情模板使用的字段名称为准。有些站点使用自定义字段、分页正文、附件或插件标签，直接套用上面的字段名可能导致内容缺失。最稳妥的方式是先复制同类型文章页的原模板，只改外层结构，并逐项检查标题、正文、分页、附件、上一篇/下一篇等现有功能是否仍然工作。

文章正文往往包含后台录入的 HTML。若正文输出为空、被转义成可见的尖括号，或格式异常，先检查原模板的字段输出方式与内容来源，不要贸然对正文做全局过滤或执行。富文本内容的处理方式应结合站点的编辑权限、过滤策略和输出上下文评估。

4. 添加自定义字段：先建立数据，再做展示

如果页面需要展示“来源”“产品编号”等并非现有模型字段的数据，先确认后台内容模型是否已有对应字段。没有时，再由管理员通过后台模型管理等现有机制添加字段，并验证内容录入、编辑和保存流程。然后在匹配的模板上下文中输出该字段。具体字段名称和标签写法需与模型配置一致；不同版本及自定义字段类型可能采用不同的输出方式。

不要把字段名、数据库列或输入值随意写进模板就当作数据已经创建。模板只能读取现有数据，不能代替字段建模和保存逻辑。若字段是 URL、HTML 或文件路径，也要确认输出时采用了合适的处理方式，不能一概视为可信内容。

五、模板中的 HTML、CSS 与安全边界

1. 结构改动不要破坏标签解析

模板里同时存在 HTML、织梦标签和字段标记。编辑时注意闭合标签、引号和成对标签。例如 {dede:arclist} 与 {/dede:arclist} 必须按当前模板引擎要求配对；嵌套标签和属性引号也要保持正确。浏览器能显示部分 HTML，并不代表模板已经正确解析。

标签属性中的引号、尖括号和大括号也可能影响解析。新增属性时，不要把模板语法当作普通 HTML 属性随意拼接。若模板页面突然显示原始标签文本、内容整段消失或生成报错，应先回退到最近一次修改，逐步排查标签边界，而不是同时改动多个区块。

2. 不把模板当作安全转义机制

数据库内容、后台录入内容、URL、用户输入和外部接口数据的可信度不同。HTML 页面中显示普通文本、放进属性、放进链接地址或嵌入 JavaScript，都需要根据上下文选择适当的转义与校验方式。不能因为内容来自后台，就断言它一定安全；后台账号被滥用、导入数据异常或编辑权限配置不当，都可能引入恶意内容。

织梦模板标签是否会自动转义，取决于标签、字段和站点实现，不能笼统承诺“系统会自动过滤”。应检查当前字段的输出行为，并针对实际输出上下文验证。未经必要处理，不要把不可信内容直接放入 onerror、onclick 等事件属性、脚本代码或 CSS。若需求确实需要展示富文本，应使用站点可信的富文本处理方案，并严格限制编辑权限与允许标签。

3. 不在模板里执行不明 PHP

不要为了图方便在模板中插入来源不明的 PHP 片段，也不要通过模板参数拼接动态执行代码。织梦不同版本和配置对模板内 PHP 的处理并不相同；开启或利用这类能力会扩大攻击面，并增加维护难度。需要新增业务逻辑时，应先评估是否已有后台功能、插件或受控扩展入口，并由开发人员在可审计的代码中实现。

4. 不直接拼接用户输入做数据库查询

模板不是数据库访问层。若筛选功能要使用搜索词、栏目 ID 或日期范围，必须由服务端逻辑按类型和业务规则验证，并采用适合当前程序与数据库接口的参数化处理。不能把请求参数原样拼接到 SQL、文件路径或命令中。具体实现受当前织梦版本、数据库驱动和项目代码结构影响，无法用一段通用模板代码安全替代。

六、模板文件与生成机制：修改后为什么没有变化

织梦站点可能同时涉及模板文件、静态生成页面、缓存和栏目绑定。保存模板后，前台仍显示旧内容，不一定是修改失败，也可能是看到的页面是此前生成的静态文件或缓存结果。可按以下顺序检查：

1. 确认编辑的是页面实际使用的模板，而不是同名的另一套风格。
2. 确认文件已保存到服务器正确目录，权限允许站点读取。
3. 按站点当前工作流程重新生成对应首页、栏目或内容页。
4. 清理该版本或站点后台支持的缓存，再进行浏览器强制刷新。
5. 用浏览器开发者工具查看实际返回的 HTML、CSS 和网络请求，区分模板输出问题与样式加载问题。

不要随意删除缓存目录、生成目录或数据库表来“清缓存”。清理范围应以后台提供的功能和站点部署说明为准。线上环境若有 CDN、反向代理或浏览器缓存，还需检查相应缓存策略；本地页面没更新，未必是织梦模板的问题。

七、CSS 与响应式调整的实用做法

将页面结构和样式分开维护，优先使用清晰的类名。不要直接给大量元素写行内样式，否则日后很难统一调整。下面是可以配合前文列表结构使用的基础样式：

.article-list {
  margin: 0;
  padding: 0;
  list-style: none;
}

.article-list li {
  border-bottom: 1px solid #e5e5e5;
  padding: 0.75rem 0;
}

.article-list a {
  color: #243447;
  text-decoration: none;
}

.article-list a:hover,
.article-list a:focus {
  text-decoration: underline;
}

.article-detail {
  max-width: 52rem;
  margin: 0 auto;
  padding: 1rem;
}

.article-body {
  line-height: 1.8;
  overflow-wrap: anywhere;
}

这是普通 CSS，不依赖织梦版本；它只负责呈现，不会创建数据或改变栏目行为。正式使用时还要结合站点原有样式表，避免选择器冲突。若新增规则没有生效，检查 CSS 文件是否被页面加载、选择器优先级、缓存和文件路径，而不是立即复制多个重复规则覆盖。

响应式布局应在窄屏下实际测试。除了横向溢出，还要检查导航、长标题、图片、表格和正文中的代码块。字体大小与间距的调整不能遮挡功能按钮。涉及第三方脚本或旧版浏览器支持时，应按站点的目标环境验证。

八、发布前的功能与安全检查清单

模板改版完成后，不要只看首页。至少检查以下项目：

• 首页、栏目列表、文章详情以及站点实际使用的其他页面类型是否正常。
• 菜单、文章链接、面包屑和站内链接是否指向正确地址。
• 列表条目数、排序、分页和空栏目表现是否符合预期。
• 标题、正文、日期、自定义字段为空或包含特殊字符时，页面是否仍可读。
• 桌面和移动设备下是否存在遮挡、横向滚动或不可操作的控件。
• 模板生成后是否有解析错误、PHP 报错、缺失文件或新增的浏览器控制台错误。
• 后台录入与编辑流程是否未受影响，栏目和内容是否仍能按原有方式管理。
• 修改是否误删了统计、分享、版权、SEO 元信息或站点已有的合规提示。
• 公开页面中是否出现调试信息、数据库错误、内部路径或未经处理的敏感数据。

搜索引擎相关内容也需要单独核验。修改模板时不要意外删除页面标题、描述、规范链接或站点原有的结构化信息；这些内容由模板、全局配置、插件或其他机制生成，实际来源要先查清。不要为了“SEO 优化”把关键词堆进页面或输出重复标题。

九、常见错误及处理方式

错误一：改错模板文件

现象是文件看起来改了，页面却完全不变。处理时重新核对模板风格、栏目模板指向和生成机制；先在页面源代码中确认修改是否有输出，再排查缓存。

错误二：把当前字段标签和列表字段标签混用

现象是字段为空、所有条目显示相同值，或页面输出异常。检查标签所在环境：循环内通常使用当前记录的字段标记，页面上下文则使用相应的字段标签。以原模板中同类字段为参照，不要仅凭名称推断写法。

错误三：重做页面时删除循环或分页代码

现象是栏目只显示固定内容、后续页无法访问。修改布局时保留原有数据循环及该版本支持的分页输出；改动后实际访问多个分页地址，而不是只看列表第一页。

错误四：把标签参数当成任意查询接口

现象是排序或筛选不生效，甚至出现异常查询。标签参数的可用范围由具体标签实现决定，参数名相似不表示行为相同。按当前版本文档和站点示例验证，不将用户输入直接传入查询参数。

错误五：用硬编码替代后台数据

少量静态文字可以写在模板里，但栏目名称、文章链接和业务数据若原本来自后台，不宜复制成固定 HTML。否则内容更新后模板不会同步，链接迁移时还需要逐个修补。

错误六：同时修改多个文件，出了问题无法定位

采用小步修改：一次只调整一个页面或一个区块，每次保存后生成并验证。用版本控制或保留带日期的备份记录变更。这样出现问题时更容易准确回退。

错误七：遇到空值就直接输出占位内容，却没检查数据链路

空字段可能表示模板字段名写错、后台没有录入、该字段不适用于当前内容模型，或当前页面使用了不同数据来源。先判断原因，再决定是否增加“无内容时不展示”等呈现逻辑。不要用占位文字掩盖数据保存失败。

十、推荐的实际工作流程

1. 写清需求。区分视觉改版、已有字段展示和新增业务能力，避免用模板解决超出模板职责的问题。
2. 核对环境。记录织梦版本、模板风格、栏目绑定、内容模型、插件和生成方式。
3. 备份并准备测试环境。确保可恢复，并避免直接在高风险的生产页面上试验。
4. 从同类原模板复制。保留已经运行的循环、字段、分页和功能标签，再逐步调整结构。
5. 每次只改一处。保存、重新生成、检查输出；遇到异常立即回退到最近一个正常版本。
6. 验证数据与安全。测试空字段、特殊字符、不同角色的后台操作及页面链接，不信任未经确认的输出内容。
7. 记录发布内容。说明改了哪些文件、依赖哪些字段、如何生成页面，以及如何回滚。

这个流程看似保守，却比一次性重写模板更适合维护旧站。尤其是由多人管理、已有大量内容或运行了多年插件的站点，模板文件中积累的定制往往没有完整文档，任何看似多余的代码都可能承担实际功能。

结语

织梦二次开发入门，关键不在于记住多少模板标签，而在于先确认数据来源和页面职责，再在正确的模板位置做最小改动。页面结构、栏目内容、分页机制、后台字段和系统程序各有边界：模板负责呈现已有数据，不应承担未经审查的查询、权限和业务流程。

从备份开始，沿用当前站点已经验证的标签写法，逐个页面测试，并保留可回滚记录，通常就能完成大多数模板调整，同时避免误伤核心功能。遇到新增数据模型或复杂业务需求时，及时从模板层抽身，先设计合适的扩展方案，再实现和验证。