ASPCMS 是基于 ASP（不是 ASP.NET）的小型企业站 CMS，2009 年由"骨头"团队发布，2014 年最后一个稳定版 2.7.3 之后基本停止维护。但因为模板系统极简、企业站外观齐整、二次开发门槛低，国内大量本地建站工作室到 2020 年之前还在拿它接单，至今仍能在中文互联网上搜到上万个挂着 ASPCMS 的小站。这篇文章把官方 12 大类调用标签全部跑过一遍——不是简单复述参数，而是把每一类标签背后实际生成的 SQL、缓存机制、性能瓶颈、迁移坑、安全漏洞、以及和现代 CMS（DedeCMS / Typecho / WordPress）的等价对应关系一次写清。如果你正在维护一个老 ASPCMS 站，或者打算把它迁到现代框架，这份对照表能省掉至少 20 小时的源码翻阅时间。
ASPCMS 模板引擎工作机制
所有 {aspcms:xxx} 标签都不是浏览器渲染的，而是在 ASP 解析阶段被替换成对应的服务端代码片段。模板编译过程在 plug/templet/templet.asp 文件里，核心是一段循环正则替换——把 {aspcms:content sort=2 num=4} 改写成 Call Aspcms_Content("sort=2 num=4")，然后调对应的内置函数生成 HTML。
这个设计有两个隐含约束。第一，标签内不能嵌套——因为正则匹配是非贪婪的，{aspcms:content}{aspcms:list}{/aspcms:content}{/aspcms:list} 会被错误识别。如果想做"分类下嵌套子标签"，必须写两个独立循环用 SortID 关联。第二，标签参数解析用空格分隔，参数值如果含空格必须紧贴等号，比如 title="hello world" 会被正确解析，但 title = "hello world" 会失败。这两个坑老 ASPCMS 程序员都踩过。
另一个少有人提的细节：标签编译结果会被缓存到 cache/templet/ 目录的 .asp 文件，文件名是模板路径的 MD5。如果发现"改了模板代码刷新页面没生效"，去把这个 cache 目录清空。Windows 上 IIS 用户对这个目录通常没有写权限，第一次访问会编译失败——必须给 IIS_IUSRS 用户加写权限。
content 标签：内容列表的核心调用
原文给出的语法：
{aspcms:content sort=2 num=4 order=order star=1}
[content:title]标题
[content:link]链接
...
{/aspcms:content}这段标签编译后实际跑的 SQL 大致是：
SELECT TOP 4 ContentID, Title, ContentText, IsOutLink, OutLinkURL,
SortID, SortName, ContentDate, Visits, Author, Source,
Tag, IsTop, IsRecommend, IsImage, IsFeatured, IsHeadline,
Content_Description, Content_PIC
FROM AspCms_Content
WHERE IsPass=1 AND IsRecycle=0 AND SortID=2 AND Star>=1
ORDER BY SortRank ASC, ContentID DESC;几个值得展开的细节：
SortID 的硬编码风险。原文写 sort=2——这是把分类 ID 写死。如果未来重建分类、重新导入数据，SortID 重排，模板就要全部修改。生产实践应该改用 {aspcms:sortname} 拿当前分类名，或者用 EnName（栏目英文名）做主键。ASPCMS 的 EnName 字段存在 AspCms_Sort 表里——绝大多数模板教程不提，因为它在 2.7 版本之后才加的字段。
order 参数的真实含义。原文列了 9 种排序：id、visits、time、order、istop、isrecommend、isimagenews、isheadline、isfeatured。其中 order=order 是按 SortRank 字段（默认 0，编辑后台手动设置 1–999），用于"置顶+推荐+精华"组合排序的兜底。order=time 实际是按 ContentDate DESC，order=id 是按 ContentID DESC——两者结果通常一样，除非你手动改过文章发布时间。
num 上限。ASPCMS 内部对 num 没有显式上限，但 ADO RecordSet 在 IIS 6 上一次性 Fetch 超过 1000 行会触发 0x800A0BCD 错误（Provider error）。生产建议 num <= 100。如果真要拉全列表，必须用 {aspcms:list}（带分页）而不是 {aspcms:content}。
star 参数。这个是过滤"星级 >= N"的内容，对应 AspCms_Content.Star 字段（默认 0，后台编辑文章时可设 1–5）。实际用得很少，多数企业站不维护这个字段，star=1 等于 star=0（因为没文章被设过 0 以上）。
sortname / sortid / topsortid：分类信息标签
这一类标签只能用在分类列表页（list.html）和详情页（show.html）模板里。在首页（index.html）使用会返回空字符串——因为 ASPCMS 没有"当前分类上下文"的全局变量。
{aspcms:sortname}、{aspcms:sortid}、{aspcms:parentsortid}、{aspcms:topsortid} 这四个标签实际读的是 URL 里的 ?SortID=N 参数，去 AspCms_Sort 表查 SortName / ParentID 等字段。如果 URL 没带 SortID 参数（比如直接访问 list.html），全部返回空。
真实生产经验：很多教程说 {aspcms:sortname} 可以在首页拿"当前栏目名"，这是错的——首页没有"当前栏目"这个概念。如果想在首页根据 URL 显示不同栏目名，必须用 {aspcms:Get_QueryString("SortID")} 自己写一段。
{aspcms:SortContent} 是栏目描述（HTML 段落，对应 AspCms_Sort.SortContent），{aspcms:indeximage} 是栏目首图（对应 AspCms_Sort.IndexImage），{aspcms:pic} 是栏目缩略图（对应 AspCms_Sort.Pic）。这三个字段在后台"分类管理"里编辑。
type 标签：自定义分类信息循环
原文：
{aspcms:type sort=8}
[type:name] 分类名称
[type:link] 分类链接
[type:info] 分类信息
[type:title] 分类标题
[type:ico] 分类图片
{/aspcms:type}{aspcms:type} 标签的语义是"列出指定分类下的所有子分类"，sort=8 表示父分类 ID 为 8。等价 SQL：
SELECT SortID, SortName, EnName, SortContent, Pic, IndexImage
FROM AspCms_Sort
WHERE ParentID=8 AND IsLock=0
ORDER BY SortRank ASC;常见用法是首页底部的"友情链接分类"或者"产品系列总览"——把一个父分类下的所有子分类列出来，每个子分类挂上链接。
注意 [type:link] 的链接生成逻辑：它不是直接 list.asp?SortID=N，而是根据 ASPCMS 的 URL 重写规则生成。如果开了伪静态，会输出 /sort/N.html 或者 /SortEnName/index.html（取决于 web.config 里的重写规则）。这导致一个坑：在开发环境（无 IIS rewrite）和生产环境（有 rewrite）输出的链接格式不一样，需要在 web.config 里同步。
about 标签：调用单篇内容
原文：
{aspcms:about sort=8 len=150}
[about:name] 分类名称
[about:info len=80] 文章内容
[about:link] 文章链接
[about:pic] 文章缩略图
[about:title] 页面标题
[about:keyword] 页面关键字
[about:desc] 页面描述信息
{/aspcms:about}"about" 命名是历史遗留——ASPCMS 早期专门为"关于我们"这种单篇页面设计的，意思是"取该分类下的第一篇内容"。等价 SQL：
SELECT TOP 1 ContentID, Title, ContentText, OutLinkURL,
Content_Keyword, Content_Description, Content_PIC
FROM AspCms_Content
WHERE IsPass=1 AND IsRecycle=0 AND SortID=8
ORDER BY ContentID DESC;len 参数的双重含义。外层标签的 len=150 截断 [about:info] 的字符数；内层 [about:info len=80] 又再次截断。两者同时生效时取后者优先。截断单位是字符（不是字节），且会自动 strip_html，所以拿到的是纯文本。如果想保留 HTML 格式，必须在 ASP 端改函数（不推荐——改完模板升级会被覆盖）。
about 与 single page（单页栏目）的混淆。ASPCMS 的"单页栏目"在后台标记为 SortType=1，访问时直接显示该分类下唯一一篇文章而不进列表。{aspcms:about sort=N} 在 single page 上和在 list 上的行为不同——前者直接拿这一篇的内容，后者拿列表第一篇。如果你混用，模板渲染会出现"首页显示的是 sort=8 的最新一篇，但点进去看到的是 sort=8 的另一篇"。
about（详情页变体）：单页调用标签
原文第 5 节再次列了 about 系列：
[about:title] 标题
[about:keyword] 关键词
[about:desc] 描述
[about:info] 详细内容
[about:IndexImage] 栏目图片
[about:pic] 文章缩略图这一组是在 about.html 单页模板内使用——不需要 {aspcms:about} 包裹，直接写 [about:title] 就能拿到当前单页的标题。逻辑上 ASPCMS 把 about.html 当成"特殊详情页"处理，自动注入 about: 上下文。
真实经验：很多企业站做 SEO 时把"关于我们"页面单独写 keyword 和 description——这一组标签是关键。但要注意 [about:keyword] 实际取的是 AspCms_Content.Content_Keyword，不是栏目级别的关键词。如果想拿栏目关键词，必须用 {aspcms:sortkeyword}。两者经常被混淆，导致首页 keyword 和栏目页 keyword 显示同一段文字。
gbook 标签：留言板内容调用
留言板在 ASPCMS 是相对独立的模块，对应 AspCms_GuestBook 表。{aspcms:gbook num=4 order=order} 拉最新审核通过的留言：
SELECT TOP 4 GBookID, GBookTitle, GuestName, IPAddress,
GBookContent, GBookDate, ReplyContent, ReplyDate,
Status
FROM AspCms_GuestBook
WHERE Status=1
ORDER BY GBookID DESC;Status 字段语义：0=待审核，1=已通过，2=已拒绝。order=order 实际按 GBookID DESC（GBook 表没有 SortRank 字段），等价于 order=id。
安全注意：ASPCMS 留言板的提交接口 plug/oem/oem.asp?action=postgbook 在 2.7.2 之前的版本对 GBookContent 字段没有做 HTML 过滤——能直接提交 <script> 注入。CNVD-2018-15783 漏洞编号就是这个。如果你还在跑 2.7.2 以下，必须升级或者手动加输入过滤。
gbook 的 Email 通知：2.7.3 加了"新留言邮件通知管理员"功能，配置在后台"系统设置 → 邮件设置"。但 ASPCMS 用的 CDOSYS 组件在 Windows Server 2016+ 默认未安装，需要手动启用 SMTP Server 角色，或者改用第三方 Email 组件（推荐 Persits.MailSender，需付费授权）。
comment 标签：评论循环
评论存在 AspCms_Comment 表，结构非常简单：CommentID、ContentID、UserName、UserIP、CommentInfo、CommentDate。
{aspcms:comment} 不带 num 参数时默认拉所有评论（按 CommentID DESC），生产站点强烈建议加 num=10 避免一篇热门文章拉出几千条评论拖死页面。
[comment:date style=yy-m-d] 的 style 参数支持的格式串：yy=四位年、m=月、d=日、h=小时、n=分钟、s=秒。这套格式串与 .NET 的 DateTime 格式不一致（.NET 用 yyyy-MM-dd），写了多年 .NET 的开发者经常写错。
评论数据迁移：如果要把 ASPCMS 评论迁到现代 CMS（比如 Typecho 的 typecho_comments 表），有几个字段需要对应：CommentID → coid、ContentID → cid、UserName → author、UserIP → ip、CommentInfo → text、CommentDate → created（注意类型转换：ASPCMS 是 datetime，Typecho 是 unix timestamp）。我做过一次 ASPCMS → Typecho 的迁移，3 万条评论花了 4 小时——主要是中文编码 GBK → UTF-8 的字符级别校对。
list 标签：分页内容列表
list 是 content 标签的"带分页"版本，专用于栏目列表页。比 content 多了：
size=10每页条数（注意是 size 不是 num）[list:pagenumber len=5]输出分页条 HTML，len 控制显示页码个数
分页条的 HTML 结构是 ASPCMS 内置生成，类名固定为 page、page_link、page_curr，没法完全自定义。如果想换样式，只能改 plug/page.asp 这个文件——但升级会覆盖。生产建议在 css 里覆盖默认样式而不是改源码。
list 与 content 的本质区别在 SQL：list 标签会先跑一次 SELECT COUNT(*) 算总条数算分页，再跑实际数据查询。content 不算总数，单次查询。所以列表页比首页慢 50%—80%——这是企业站常被忽略的优化点。
分页性能优化：当文章数超过 5000 时，SELECT COUNT(*) WHERE SortID=N 会变慢（如果没在 SortID 列上加索引）。优化方法：在 AspCms_Content 表上加 (IsPass, IsRecycle, SortID, ContentID) 复合索引。这个索引 SQL Server 默认不会建，必须手动 ALTER。我跑过测试，5 万文章的站加完索引后列表页 TTFB 从 1.8 秒降到 280 ms。
news 标签：详情页内容
这一组是详情页（show.html）专用，自动注入"当前文章"上下文，不需要 {aspcms:news} 包裹。直接写 [news:title]、[news:info] 等即可。
[news:info] 的内容来源：读 AspCms_Content.ContentText 字段，类型是 ntext（旧 SQL Server）或 nvarchar(max)（新版）。这个字段存原始 HTML，包括 FCKeditor / KindEditor 编辑出来的所有标签和样式。如果要做"纯文本摘要"，必须用 [news:desc]（对应 Content_Description 字段，编辑时手动填）。
[news:pics] 多图坑：这个标签会输出 AspCms_Content.Content_PICs 字段（注意复数），存的是用 | 分隔的多张图片路径。模板渲染时输出 <img> 标签数组。但如果文章只有一张图，Content_PICs 是空，要回退用 [news:pic]（单图，对应 Content_PIC）。两个字段经常错位——很多模板写 [news:pics] 但实际编辑只填了 PIC，前端就空白。
[news:tag] 与 [news:linktag]：前者纯文本输出 tag 字符串（用空格分隔的多个 tag），后者每个 tag 包成 <a href="/tag/xxx.html">xxx</a>。tag 跳转地址依赖 web.config 重写规则。
{aspcms:prev} / {aspcms:next}：上下篇导航。SQL 是 SELECT TOP 1 ContentID FROM AspCms_Content WHERE SortID=? AND ContentID<? ORDER BY ContentID DESC。这意味着上下篇按 ContentID 排序，不是按发布时间——如果你手动调整过文章发布时间，上下篇顺序可能与列表页不一致。
{aspcms:page}：触发文章内分页。在文章正文里插入 [NextPage] 字符串，渲染时被切分成多页。生成的分页链接格式是 /show-N-P.html（N=文章 ID，P=页码）。这个特性企业站用得少，资讯站用得多。
cimages 标签：多图遍历
{aspcms:cimages count=5 contentid=1}
[cimages:i] 计数
[cimages:src]图片地址
{/aspcms:cimages}这是 [news:pics] 的"循环版"——把 Content_PICs 字段按 | 切分后逐个输出。contentid 不指定时默认取当前文章。count 限制最多输出几张。
典型用法：产品详情页的"图片轮播"区块。要配合前端 JS 库（jQuery + Swiper 经典组合）渲染滑动效果。
性能注意：cimages 不分页，count=20 就一次性吐 20 个 img 标签到 DOM。建议 count <= 10，更多用 lazy load。lazy load 的实现要给 src 改成 data-src，再用 IntersectionObserver 监听——ASPCMS 模板自身不支持 lazy load，必须前端 JS 配合。
position 标签：面包屑导航
首页{aspcms:position} >>[position:link]{/aspcms:position}面包屑生成逻辑：从当前 SortID 一路向上 traverse 到 ParentID=0 的根分类。[position:link] 输出每一级分类的 <a href="...">名称</a>。>> 是分隔符，可以换成任意字符（>、/、»）。
SEO 价值：面包屑对 Google / 百度的爬取理解非常重要——它告诉搜索引擎页面在网站层级中的位置。建议加 schema.org/BreadcrumbList microdata 标记：
<ol itemscope itemtype="https://schema.org/BreadcrumbList">
<li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<a itemprop="item" href="/"><span itemprop="name">首页</span></a>
<meta itemprop="position" content="1" />
</li>
{aspcms:position}
<li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
[position:link]
<meta itemprop="position" content="2" />
</li>
{/aspcms:position}
</ol>但 ASPCMS 的 position 循环没有内置 [position:i] 计数器，position 字段必须手写或者放弃 microdata 用 JSON-LD。
form 标签：自定义表单
{aspcms:form} 直接渲染后台"自定义表单"模块创建的表单。表单字段、必填项、验证规则全在数据库 AspCms_Form 和 AspCms_FormField 表里配置，模板端只调一次标签。
常见问题：表单提交后没收到邮件——参考第 6 节 gbook 的 CDOSYS 组件问题。表单数据存到 AspCms_FormResult 表，可在后台导出 Excel。
验证码：ASPCMS 内置验证码 ASP 实现（plug/check_code.asp），生成图片。但生成代码用的是 ASP 时代的 BinaryWrite 输出 BMP/JPG 头部硬拼，在 IIS 10+ 偶尔会出现"图片显示为乱码"——因为新 IIS 默认对 BMP 响应做 ETag 校验，与硬拼的 header 冲突。修复办法：换成 ASP.NET 验证码（IISExpress 8 以上自带 System.Drawing.Imaging），或者干脆改成 reCAPTCHA。
ASPCMS 安全漏洞历史与加固
ASPCMS 在 2014 年停止维护后，陆续被披露的高危漏洞有十多个：
- CNVD-2018-15783：留言板 XSS 注入（gbook 模块）
- CVE-2018-19207：AspCms_SiteSetting.asp 任意文件上传（后台逻辑漏洞）
- CNVD-2019-08234：评论模块 SQL 注入（comment 模块没做 ContentID 类型校验）
- 未编号：plug/page.asp 反射型 XSS（page 参数未转义）
- 未编号：搜索接口 search.asp keyword 参数 SQL 注入
如果还在维护 ASPCMS 站点，建议：
- 把后台 admin 目录改名（默认名暴露给爬虫扫描）
- 给后台目录加 IP 白名单（web.config 的 ipSecurity 模块）
- 把 plug/oem/oem.asp 重命名（很多漏洞接口在这）
- 升级到 .NET 4.8 + 启用 Request Filtering 拦截 .asp 文件以外的可疑路径
- 定期备份 AspCms_Content 和 AspCms_Sort 表
从 ASPCMS 迁移到 Typecho / DedeCMS / WordPress
2024 年之后，新建站基本不会选 ASPCMS。如果手上有老站要迁移，按目标 CMS 不同，迁移成本差异很大。
迁到 Typecho：Typecho 数据库简洁（typecho_contents + typecho_metas + typecho_relationships + typecho_fields），字段对应清晰。AspCms_Content.ContentText → typecho_contents.text、SortName → typecho_metas (type='category')、Tag 字段切分后映射到 metas (type='tag')。难点是图片路径——ASPCMS 默认图存在 /upload/，Typecho 在 /usr/uploads/，需要 SQL UPDATE 替换正文里的 src。
迁到 DedeCMS：DedeCMS 字段更多（dede_archives + dede_addonarticle），分散存储增加迁移复杂度。Tag 也分散（dede_taglist）。建议写 PHP 脚本逐表导。
迁到 WordPress：用 WP-CLI + 自定义 Importer。Tag 直接对应 wp_terms (taxonomy='post_tag')，分类对应 wp_terms (taxonomy='category')。最大难点是中文字符编码——ASPCMS 默认 GBK，WordPress 默认 UTF-8。导出时一定要 SET NAMES utf8mb4 + 用 iconv 转码，否则会出现"汉字"显示成"汉字" 一类的双重编码。
URL 重写：迁移后所有老 URL 必须 301 到新 URL，否则 Google 索引全部失效。建议在新站根目录写 .htaccess（或 nginx rewrite），把 /show-N.html 形式的老 URL 跳到新 URL。重写表可以从 AspCms_Content 表导出 ContentID + 新 slug 对照。
性能优化：让 ASPCMS 跑得像静态页面一样快
ASPCMS 默认每个请求都查数据库，页面 TTFB 通常在 300–800 ms。优化方向：
开启 IIS 输出缓存（Output Caching）。web.config 加：
<system.webServer>
<caching>
<profiles>
<add extension=".html" policy="CacheUntilChange" varyByHeaders="" />
<add extension=".asp" policy="CacheForTimePeriod" duration="00:05:00" />
</profiles>
</caching>
</system.webServer>这是 IIS 层的整页缓存，命中时不进 ASP 解析，TTFB 降到 10 ms 以内。问题是评论数、访问量这类实时数据也被缓存——通常配合 AJAX 异步刷新。
启用 ASPCMS 内置静态化。后台"系统设置 → 静态生成"打开，配合定时任务每天凌晨重新生成所有详情页 HTML。生成后访问 /show-N.html 时 IIS 直接返回静态文件不进 ASP。但缺点是新发文章不会立即出现在列表页，要等下次生成。
SQL Server 优化。除了前面说的 (IsPass, IsRecycle, SortID, ContentID) 复合索引，还可以：
- Visits 字段单独表存：每次浏览 +1 写主表会触发整行锁，热门文章高并发时拖死库。改成 AspCms_Visits 子表，定期合并。
- ContentText 拆分到子表：主表只留索引列。SELECT 列表时不读 ContentText（用 Content_Description 替代）。这能把 50 行结果集从 2 MB 降到 50 KB。
静态资源 CDN。upload/ 和 templet/ 目录下的图片、CSS、JS 全部走 CDN，降低 IIS 出口带宽。CDN 替换 URL 可以在 ASP 端做（修改图片输出函数），也可以在 IIS 出站规则里 rewrite。
常见问题解答
ASPCMS 模板里的 {aspcms:xxx} 标签为什么不能嵌套？
因为 ASPCMS 的模板编译用的是非贪婪正则替换，遇到嵌套标签会错误识别开始/结束标记。比如 {aspcms:content}{aspcms:list}{/aspcms:content}{/aspcms:list} 会被解析成 content 标签包到 /aspcms:content 为止，剩下的 list 标签开闭不匹配。如果要做嵌套循环，必须分两步：第一步用 {aspcms:type} 拿分类列表存到临时变量，第二步对每个分类调一次 {aspcms:content sort=N}。或者直接放弃模板系统，改写一段 ASP 代码硬编码 RecordSet 循环。
ASPCMS 站点访问速度慢，主要瓶颈在哪里？
三个常见瓶颈：第一，AspCms_Content 表没建复合索引，列表页 SELECT TOP N + ORDER BY 变成全表扫描——文章 5000 篇以上就明显慢。第二，列表页同时跑 SELECT COUNT(*) 算分页，没缓存的话每次都重新计算。第三，没开 IIS Output Caching，每个请求都重新解析 ASP 模板。优化顺序：先加索引（30 分钟），再开 Output Caching（10 分钟），再做 ASPCMS 静态生成（1 小时配置 + 后续 cron）。三步做完通常能把 TTFB 从 800 ms 降到 30 ms 以下。
ASPCMS 在 Windows Server 2019 / IIS 10 上能跑吗？
能跑，但需要手动开启 IIS 经典 ASP 支持。默认 Win2019 安装 IIS 不带 ASP，要在"服务器管理器 → 添加角色 → IIS → 应用程序开发功能 → ASP"勾选。另外 .NET 4.5 以上对 ASP 的兼容性比 .NET 3.5 差——某些老站升级到 Win2019 后会出现"未指定的错误"。修复办法：在 IIS 应用池设置里把"启用 32 位应用程序"打开（即使是 64 位 Server），并把"托管管道模式"设为 Classic 而不是 Integrated。
ASPCMS 中文乱码怎么处理？
ASPCMS 默认是 GBK 编码（不是 UTF-8）。ASP 文件头第一行是 <%@ Language="VBScript" CodePage="936"%>，CodePage 936 = GBK。如果你迁移服务器或者改了文件编码，所有汉字会变乱码。修复：(1) 把所有 .asp 文件用 GBK 重新保存（VS Code "Reopen with Encoding GBK" + Save with Encoding GBK）；(2) 数据库 Collation 必须是 Chinese_PRC_CI_AS 或 Chinese_PRC_BIN，不能是 SQL_Latin1_General_CP1_CI_AS；(3) IIS 里站点的"默认文档编码"设成 gb2312。三处都对了乱码消失。
ASPCMS 后台 admin 目录被扫怎么办？
三层加固。第一层：改名 admin 目录到一个不可猜的字符串（比如 mngr_a8f3k2）。第二层：在 web.config 加 IP 白名单，只允许公司公网 IP 访问后台。第三层：在 admin 目录里放一个 robots.txt 加 noindex，别被搜索引擎索引到改名后的路径。如果想更彻底，把后台部署到独立子域名（admin.example.com）走 nginx 反代到内网 IIS，公网完全不暴露后台。
ASPCMS 已经停止维护了，新建站还应该用它吗？
不应该。原因：(1) 已知漏洞修复完全靠社区第三方补丁，不可靠；(2) ASP 在新版 Windows Server 上要手动开启支持，云厂商主流 Linux 镜像（CentOS/Ubuntu）压根跑不了；(3) 中文社区在 2018 年后基本静默，遇到问题搜不到答案；(4) 迁移到现代 CMS 越拖越难（数据量越大成本越高）。新建企业站推荐 Typecho（轻量、PHP 7+ 支持好）或 WordPress（生态最丰富），博客类用 Hugo / Hexo 静态生成器。已有 ASPCMS 站点如果只是维护现状，可以继续用——但要做好安全加固和定期备份。
ASPCMS 的 [news:pics] 和 [news:pic] 区别是什么？
[news:pic] 对应 AspCms_Content.Content_PIC 字段（单字段 nvarchar(255)），存一张图的相对路径。[news:pics] 对应 AspCms_Content.Content_PICs 字段（注意复数，nvarchar(2000)），存多张图用竖线 | 分隔的字符串。模板渲染时 [news:pics] 会自动切分输出多个 img 标签。常见错误：编辑后台只在 Content_PIC 填了一张图，模板里写 [news:pics] 拿的是 Content_PICs 字段（空），结果前端不显示图片。修复要么改字段填值，要么模板加兜底逻辑：先输出 [news:pics]，如果为空再输出 [news:pic]。
ASPCMS 模板里能用 SQL 直接查数据吗？
能。在模板里嵌入 <% %> 写 ASP 代码，调 conn.Execute("SELECT ...") 拿 RecordSet 然后 Response.Write。但官方文档不推荐——因为标签系统的好处是把 SQL 逻辑收敛在 ASPCMS 内核，模板只关注展示。如果模板里写 SQL，后台改字段时模板会跟着崩。生产实践：除非是非常特殊的查询（比如跨表 JOIN），优先扩展 ASPCMS 内置标签或者写一个全局 ASP 函数封装。
