建站/框架

我需要做什么？

阅读本文，选择符合您需求的框架，并按照提供的安装指南进行最终操作。

• 例如：Mediawiki、Typecho

　

前言

从技术流程上讲，我们需要先部署web环境再安装框架，但从策略逻辑上讲，我们需要先敲定框架，再部署需要的环境。

选框架要谨慎：

• 体量上：像wp，功能多、插件多，但适合做论坛或者商业化的东西，做个人博客有些太折腾及臃肿；
• 创作上：长期文本创作，我更喜欢可视化编辑——所见即所得，就如同主流社交平台编辑文章的界面一样，我想看到实时的渲染效果；
• 体验上：一开始我用的wp，大部分时间都花在了处理框架问题上^{（比如优化、设置、格式转换等）}，后来试图换成Typecho，但仍旧对编辑功能不满意，并且默认主题不好看，使用别人的主题花了很多时间在调整细节上，但仍旧有诸如页面上的编辑按钮被其他元素盖住无法触击等问题^{（非框架纯主题问题）}，最后换成了mediawiki，启用可视化编辑后，才安下心来写东西，也是wiki.scio.icu使用的框架。

目前已写指南：

• MediaWiki 初始化安装移步：建站/MediaWiki、拓展等功能的使用移步：建站WIKI功能
• Typecho 安装指南移步：建站/Typecho

但在这之前，建议您先阅读本文的以下章节，了解我对它们的纯主观意见^{（限于默认设置或极其简单就能实现的功能）}，以便助您更好的选择。

　

MediaWiki

　　Mediawiki是基于WikiText语法的内容管理平台，与markdown语法的绝大部分功能兼容。也是WIKI及本站所使用的框架，我用过的博客框架不多，也只有mediawiki留住了我创作的积极性，作为平均每天都要编辑好几次、使用两年半^{（2022-05至编辑时的2024-11）}、累积码了百万字单位的mediawiki使用者，我钟爱于它，但它也并不完美，也有很多弊端，且听我细细道来。

本质

　　Mediawiki是由页面构成的，所有内容都是页面，普通的页面是页面、分类是页面、文件是页面、用户是页面、模板是页面、xx讨论是页面、就连设定框架css/js样式的亦是页面。区别它们的是“命名空间”，除了主命名空间外都具有前缀^{(或者说主空间的前缀为空)}，如分类:xxx，您可以在 特殊:所有页面 中检阅它们。

　　底层设定让这些命名空间有不同的展现形式与功能，比如文件页面会显示图片信息，分类页面会统计所有辖内页面，但他们本质仍旧是页面，除了设定css/js样式的特殊功能页面外，它们具有相同的风格，可执行相同的操作。

　　如此设计有优点：一切由自己支配，自由度高。您可以查阅：Wiki:SCIO系列站点WIKI章程 ，后半部分罗列了WIKI的所有分类与页面；前半部分是统计的一些大类别的索引，而一些具有较多文章的类别我又为其创建了单独的索引页，这使得管理跨类别/主题较多的文章时十分便利——类别越多其优势越明显，因为类别或文章太少反而显得臃肿。这在普通的博客框架中是很难做到或维护繁琐的，因为它们会混为一谈或毫无章法^{(粗暴的按照发布时间排序，或标签/分类内按照拼音或字母顺序排列)}，而给他们建立索引页的繁琐度又远超mediawiki——况且这样一来这些传统博客框架依据标签与分类自动建立的索引的机制又失去了其价值。

　　当然也有其缺点：如你所见，一切都需要你自己构建，相对较为繁琐，如果你无法借助脚本自动化一些繁琐流程，那就只能手动维护这一切。所有的索引页/汇总页都是手动编辑与维护的，而不是常规博客框架发布自动建立索引/归档。

优势

编辑的易用性：

• 真·可视化编辑，在页面内直接编辑而不需要跳转到专门的工作区，所见即所得，适合长期/频繁编辑的场景，尤其是记录生活类博客；
  • 可视化编辑器支持的功能类似于typora的升级版，除了实验性与特殊用途外，所有文本创作都可以用可视化编辑器单独完成。
  • 源代码编辑器配合官方提供的体验增强扩展使其用起来也不难，1.41.1版本已经引入了在编辑器窗口“显示预览”的功能，虽然有几秒刷新延迟或需要手动刷新，但比近似于提交的那个预览更方便(那个预览会刷新一下页面，也就使编辑痕迹无法通过ctrl+z找回)。
• 插入內链十分方便，不必输入url，输入页面标题即可，这使得对站内文章相互索引有强烈需求的用户省去很多麻烦。
  • 需要顺序输入标题部分，如输入“你”，它只会以此为起点索引“你xxxx”的文章。
• 支持嵌入HTML代码，其弊端见劣势章节。

UI的干净简洁：

• 空间利用率大、看着舒服、适合长篇幅文章。
  • 推荐vector旧版(2010)皮肤，维基百科目前用的就是新版(2022)皮肤，多了一些无意义空区，且文本区域最宽948px，旧版是自适应；typecho默认的行间距都可以通行航母了，短篇文章还好说，像wiki:生与死这种长篇文章就体现出臃肿程度了。

组织内容的强势：

• mediawiki是由页面组成的，可以给页面设置类别（不限数量），而类别也是页面，可以正常填充内容^{(不支持可视化编辑器但支持wikitext语法)}，因此可以嵌套类别，实现层级的分别；
  • 简单来说就是一个可以嵌套的分类机制，我是采用一个大一統但无意义的根类别，下面接几个二级类别，然后慢慢细分；
  • 在创建页面时，点击“≡”，选择“分类”，设定为什么，就归类于什么名下；“分类”本身也算页面，所以也可以让分类挂靠到其他分类下^{（但分类命名空间只能源代码模式下编辑，格式为“[[分类:要归类到哪个分类名下]]”）}。
• 但默认的分类页面对所有旗下分类及文章的汇总方式同其他主流框架的类别机制一样，排序按照拼音顺序不能自定义，所以我是使用新建一个总的页面去索引一切文章，其他主流框架也可以这么做，但是mediawiki插入内部页面十分方便，修改起来也顺手，可以提高编辑效率。
• 因此对于 涉及多话题 但 每个文章间又紧密联系 的创作需求非常好用；当体量变大时，大索引页 索引 小索引页，小索引页 索引 辖内文章，不用担心跨类别较多时难于管理。
  • 需要手动写索引页，但由于是页面，怎么写索引、说点什么，自然是看心情随便安排。而常规博客框架只适用于每篇文章仅题材相同但互相独立的情况，除非是常用内容，否则很难想起旧文章，其框架特色默认的归档内容也就只是归档作用，除非手动建立索引页。
• mediawiki是为多人协作与维护内容类项目而生的，在编辑内容上所支持的自然比其他框架更多，比如比如站内文章/一些固定词汇发生了变动，要修改其他页面对其的索引，自有“特殊:替换文本”的功能去帮助简单的实现。
• 简单即自由。

劣势

编辑的缺陷：

• 在源代码模式下编辑内容，两行回车才是换行；可视化编辑器下一行回车即可，生成的代码其实就是两行回车^{（Markdown就是如此）}，因此若要将源代码移植到非wikitext、markdown语法场景，需要额外做些工作^{（比如批量替换换行符）}；
• 多个连续的回车/空格在提交编辑后会被视为只有一个、标题上一行的回车会被无视；
  • 所以我大量使用全角空格“　”^(u+3000)占位）。
• 引用中的文本、代码框文本等样式前后容易出现换行失效的情况；
  • 解决方案：在源代码模式下，以：<blockquote>Q：我需要做什么？……、</syntaxhighlight>'''添加了拓展文件后，无法访问页面'''……：为例，在标记标签和正文文本间用回车换行即可，但是否失效只能保存(渲染后)才知道。

• 源代码模式下原生可以调用html的style元素，设置后可插入html代码，以便实现特殊需求，但很多情况都无法在可视化编辑器下快捷编辑；
  • 一般来说，于可视化编辑器下能预览的内容都可以进行直接编辑（修改、复制、粘贴）；
  • 但诸如直接插入html代码和一些拓展实现的功能，在可视化编辑器下都是以按钮或元素卡片的形式出现，其编辑跟源代码模式下无甚区别甚至无法编辑，显现不出可视化编辑器的优势。
• 解析器与编辑习惯可能冲突，比如“#”“*”在wikitext中是列表元素标识，在可视化编辑器内输入此类符号再接空格，是一个很普通不过的编辑习惯，但在wiki中会识别为wikitext元素并解析/渲染为列表样式；
  • 可视化编辑中可以ctrl+z取消样式，正常来说保存后不会被再度解析，但有抽风的风险；源代码模式下编辑需要添加“<nowiki>内容</nowiki>”来阻止渲染。
• 对于非可视化编辑器主用功能，在调用或渲染时或有抽风：如代码框视角置右、中文(全角)引号导致定位不准；插入外链图像的渲染规则不一致(中文名的图片在页面中不会渲染，在可视化编辑器中会渲染)等。

性质上的劣势：

• 因为它为了多人协作、公共项目而生，主流应用场景还是维基百科等项目，而它们都是用源代码编辑器，开发团队的重心也不在个人用途上，就延伸出一系列个人用很难受的功能，比如不支持^(视频)或最低限度的支持^(图像)插入外部资源、上传文件的多步验证。
• 个人博客用途中，可视化编辑器是最主要的核心，而对于高级功能——以模板或嵌入html代码为例的任何非可视化编辑器所能提供或不能完全提供的功能——都需要在源代码编辑模式下完成，这就要你审视自己的实际应用场景、需求、对wikitext语法编辑的接受度等。
• 由于用于个人博客和用于维基项目的用户群体数量差异，无法妄想其官方团队为个人博客用途做优化。

对于功能/题材单一的场景：

• 如果您的博客涉及内容单一或跨题材很少，尤其是每篇文章间是独立的^{（或许题材相同，但绝对没理由相互索引）}，那么建议您使用其他主流博客框架。无他，上手更简单、发布更省心就是完全足够的理由，不是所有人都有维护索引页的需求和精力，而用wiki又大量创作文章可不建立索引页，那同样是放弃了wiki的强势之处。
• 除了常规博客，对于单一系列类内容，尤其是指南类，或许wiki.js这种才是更好的选择。

对于插入媒体资源需求强烈的场景 / 图片管理：

• 图片上传和管理机制对于个人博客用途来说十分不友好：
  • 前者是上传需要多步确认^{（如可视化编辑器中需要勾选版权确定的复选框、填写文件描述、设定略缩图和围绕文字的样式）}
    • 在特殊:上传文件中可以只拖动文件，自动按照文件名填写页面名并直接提交即可；
    • 也有MsUpload这类(基于源代码编辑器的)批量上传工具。
  • 后者是会自动压缩图片为各种分辨率造成大量冗余、有着“压缩后的大小远超原图”的现象、图片存储路径混乱不便统一管理；且不支持avif等非上古格式，我都是上传图片到服务器后插入直链；在我更改图像上传策略前，我在WIKI实际上传了50MB的图像，但是在WIKI的文件夹中，加上各种分辨率的版本，占用空间达到了400MB；
    • 这看起来也不是多，但是我非常在意，尤其是图像是琐碎的分布到各种文件夹中，如果后续我要备份WIKI，只能备份/恢复数据库+这些臃肿的文件，所以我采取上传外链的形式插入图片；
    • 如果只是上传图像，按照指南设置好模板，选好托管图片的网站（或者自建图床）也不麻烦，但我的目的是上传小体积的图片，因此需要做些额外的操作，比如压缩图像、上传到自己的另一个服务器中^{（通过sftp）}避免占用scio.icu域的站点性能，就显得麻烦了点——这可不是“麻烦一点”的问题，因为频繁编辑的情况下，会麻烦很大，就会像typecho等框架一样影响编辑的动力，因此我在寻找一个更方便的策略/扩展让可视化编辑器体验增强的功能。
    • 短期内的方案是减少对媒体文件的引用。
• 可视化编辑器虽然支持复制粘贴上传图片，但需要多步验证；虽然可以通过插入html来插入图片，并复制粘贴现有元素、修改参数，可以应对绝大多数单纯插入图片的需求，但其不属于mediawiki内资源，便无法实现如cargo等特殊功能的汇总并展示海报的需求^{（或许可以，但要自己造轮子）}；
• 其嵌入外部图片、youtube等平台视频都是要通过模板、html代码等方式实现，而这是可视化编辑器的劣势，自然也是受其吸引的mediawiki的劣势。

UI：

• 对手机等小屏设备访问不友好。

性能的缺陷：

• mediaiwki的旧版本有些兼容性问题，一开始我踩的坑真不少，新版本兼容性好多了，不用考虑php^(支持7.4+)、mysql^(支持5.7+)版本什么的了；
• 但是新版本的mysql^(8.0+)比较吃性能，本来mediawiki就不以性能著名，对于租低配置vps的个人玩家并不算友好，在我还是1c2g1M时，更新环境版本后，由于清理了数据库，访问速度是提升了^{（总体还是要1-3s）}，但是提交编辑有时会很慢^{（进入编辑状态慢或保存很慢，久的能达到20s+，跟编辑量无关，可能是数据库上的问题，如果是用的宝塔，低于2核是会提示不让安装mysql8的）}；
  • 在服务器未变化的情况下，将框架从1.40升级至1.41，似乎提交慢的问题消失了。
• 不过SCIO系列站点现在取消任何计数功能了，之前有的时候也就是博客日IP 50-100，主站10-，WIKI未知但不会很多，所以抗迸发效果如何未知。

中性

编辑记录：

• 保存所有历史编辑记录，前端也不是真正的删除；
• 所有数据还都在数据库，只是被删除内容只能由有权限的用户^{（管理员）}访问和恢复，一旦产生大量垃圾数据，还是得通过一些插件/扩展清理；
• 清理所有记录很简单，但是针对性的清理就麻烦许多，且日志目前仍旧不能删除^{（创建和删除页面的日志）}。

扩展/模板等功能：

• 默认支持的功能不算太强大，mediawiki需要调教才能用起来顺手，否则只能使用一些基础的文字编辑；
  • 这个看个人需求，但是就我来说，个人博客不只是文章创作，或者简单的加个脚注贴个链接，还是需要很多高级样式与功能插入外部资源的。
• 如果要进行调教，那么wiki确实强大，除了丰富的官方社区及文档外，市场占有率导致的人口基数也是一大利处^{（如维基百科、萌娘百科等都基于mediawiki框架）}，抄作业方便；
  • 不过调用模板等高级功能都需要在源代码编辑器下操作，虽然可以便捷的切换两种编辑器。

个人想法

自定义：虽然这不是为个人博客而创建的，但是我总觉得非常适合用来写博客，不过除了“分类”外，是不会自动建立索引的，比如Wired世界开发进度中贴出来的文章，都是我写完之后再手动加进去的，只是一切都在web端操作，并不麻烦。除此之外，它就是单纯的一个由页面组成的框架，想怎么用，完全随你。

历史内容：在我看来，诸如typecho等博客框架，有一种感觉就是，旧的文章很难找到，一经发表就像离开了一样，而建立索引的维护成本又非常高，在wiki中，得益于插入內链的便捷程度，非常适合做这种工作；以及常规的博客只适合单调场景，比如blog.scio.icu只能容纳下unraid及相关的文章，像我在WIKI中写的大量不同类别的文章，在普通的个人博客下很难分类与组织，会很臃肿与难以找到，并且需要变动时，编辑起来十分不便，而如果为其创建索引页，那就是舍弃mediawiki所长用个人博客之短。

优缺点：我说了它很多缺点，是因为我在真正大量的、频繁的使用它，而typecho，已经被我遗忘了。

mediawiki确实有一些复杂的功能，对于专业的wiki人来说似乎也是很适用的，比如用变量定义字符串，正文中需要使用该字符串时使用此变量，在编辑时或许并不比直接用字符串更简单，但维护时却更加的便捷与精确，但总的来说编辑时确实麻烦，一般的wiki人也不用，普通用户更不用。更不要提模板、模块、微件、扩展等等功能，它复杂的是上限和特殊功能，对于基础的文字编辑不需要考虑甚多，可视化编辑器工具栏提供的功能够我所有非折腾类文本创作使用，其他高级功能无非是图个新鲜与玩个花样。

总的来说，mediawiki适合文本创作、自己组织页面，在文章篇幅较大、不同文章跨类别较多、文章数量可观的情况下，mediawiki是非常适合的。而如果只是偶尔发一篇文章、很少后续维护、话题比较随机、喜欢其他框架美观的主题、对我认为的优点并不感冒、经常插入外部视频或图片，那么mediawiki就不适合您。

但我不建议让“我没有那么多好写的”成为使您决策因素。你看我写了如此多的字，但我在建设wiki前知道自己能有如此多东西可写吗？我不知道，我也难以置信，因为这是我累积的产物。我将那些本来或许要被抛弃的想法拾了起来， 它们有些确实被遗忘了，但有些自成一体了，wiki:小知识、Favorites:兴趣博物馆莫不是如此，整个Wired世界系列更是如此，就连OSINT项目不也是沉淀的结晶吗？捕捉想法， 并给它一个机会。

我并不写博客文章， 而是按照主题维护系列内容，所以传统博客于我而言没有任何优点，反而他们的优点是我认为的缺点。

　

Typecho

基本功能：基于markdown语法的个人博客平台。

优点：轻量化

缺点：编辑功能（半可视化编辑，非所见即所得。）

建议：适用于对组织内容没有太大要求的用户，按照简单的标签和类别制度进行分类，文章一经发布很少去变动的情况下；或使用的场景(话题)比较单调，只是发表想法，不太需要组织内容的场景。

参考：https://blog.scio.icu/

　

其他推荐：

• wordpress：对于我的需求来说，wp插件很多，可以实现很多功能，很强大， 但有些臃肿，适合做论坛或商业化的站点，生活化的博客我个人不看好 。
• 您也可以通过中意的网站页面底部的版权标识来得知其使用的架构/框架与主题，或者发给我，我帮忙参考一下。