这个页面也集中回答邮箱收到的，被问了很多次的问题。
很多读者找到这里是为了看李守中翻译的文档。为了方便读者，李守中单开了一个 翻译 模块，读者可以从页面顶部进入。
该站点为李守中 (联系方式: lsz.sino@outlook.com) 的个人站点。这个站点的用途是为在线查阅笔记提供便利，后来，李守中也把一些自己写的/收集来的文章放在这里。但是，李守中水平有限，请诸位务必谨慎参考。
站内除 工具 模块 (/tool/ 路径下) 之外的页面都是静态页面，不需要 JavaScript 解释器参与页面解析。工具 模块内的功能均使用 Vue3 制作，页面正常运行需要 JavaScript 解释器参与。
没有做 RSS 的打算。站内文章多为笔记类型，站点的主要目的也是为资料的在线查阅提供方便。
这意味着，站内文章的内容会少量多次地更新。用 RSS 不停地给你们推内容相似的文章，很烦。
李守中在制作笔记的时候根本没有考虑除李守中以外的，任何人的阅读体验。
所以，看不懂某些笔记是非常正常的事情。如果读者有疑问需要解答，可以发邮件联系李守中。李守中会尽量回答。
好问题。诚然，图片的信息密度更高，信息传递相较于文字也更加直观。但是，对应地，制作精良的图片也需要相当多的时间和精力。
在李守中能用文字清晰表达的情况下，李守中不想花太多时间和精力来制作图片。
同时，图片远比文字占用的硬盘空间大，传输图片也比传输文字消耗更多的网络与计算资源。再加上，多数情况下，文字，已足够描述李守中的思想。这些因素叠加在一起最终导致了李守中很少在笔记里用图片。
当然，要表述复杂逻辑的话，还是图片比文字更省事。
简言之，在文字表达能力够用、写出的东西理解起来不费劲的时候，就不用图片了。
好吧。被问的是，为什么 UI 那么丑...... 有两个原因。
第一，李守中希望站内文章可以被 w3m 等 text-based 浏览器正常显示。使用现代感很强的设计的话，让各种奇形怪状的浏览器 UI 一致很难做。
第二，李守中喜欢类似于 Windows2000 的那种简单、耐看的，信息密度极高的 UI，不喜欢大片的空白。
所以，在 UI 方面，李守中选择基于文字来做。纯文字嘛，视觉刺激总是弱一些。但是，现在这版站点，不需要交互的地方不使用任何 JavaScript、克制地使用 css、只使用纯文字 UI，做起来可费劲了。
站点一共有过五版。第一版是用 Golang (gin, goldmark, cron) + Bootstrap + ZTree + highlight.js 组装的。但后来发现 Golang 的坑还是有点多，就整个用 Java 重写了，用的全是 spring boot, freemarker, flexmark 等等常规且常用的组件，UI 部分就是用自己写的 CSS 简单排个版 + 体积更小的 prism.js 做代码高亮。这就是第二版。到这里，笔记格式一直都是 Github Flavored Markdown。但随着李守中的笔记排版越来越复杂， Markdown 就不够用了。
第三版主要解决的就是复杂排版的问题 (但也没彻底解决)。在为文档源文件选格式时，排除 Markdown，程序员间出名的文档格式中，除了 latex 就是 org mode 了。又由于 latex 的编辑体验不如 org mode，所以，最终，笔记被迁移到了 org mode 上。连带着，主力编辑器也由 VSCode 变成了 Emacs。
但还有一个问题，Java 没有解析 org mode 的包。而李守中又不想自己写 org mode 解析器，但想要笔记能被正常访问又得用 org mode 解析器把 org 文件渲染成 HTML 文件。这问题有个死循环。既然问题无解，那么另一个思路就是解决提出问题的人 (指 Java)。所以，李守中最后抛弃 Java，直接用 org mode 自带的 ox-publish 生成了一个静态站放在 Nginx 下面。
这次直接把后台简化到消失，站点生成之后自带基础样式，自己再写点 CSS 简单排个版、改个字体就能看，非常方便。但是这个方案的坑在于，虽然使用 org 原生支持的 htmlize 可以在 org file 导出时自动给代码块加高亮，但当 emacs 以 batch 模式(non-interactive mode) 启动的时候，emacs 不会加载内部样式，而 htmlize 读不到当前
emacs session 中的样式的话，就会使用最简单的样式 (只有斜体、粗体、下划线和黑色默认字体)。所以，李守中就只能用 org-html-htmlize-generate-css 导出 emacs 的内部样式到 CSS 文件之后，再在每个导出的 html 的 head 块中以加载外部 CSS 文件的方式来加载 htmlize 的代码高亮。这就是第三版。(不用自己写后台逻辑真省事啊...)
第四版主要修改了文档内代码块的渲染方式和配色。大概半年后，李守中重写了一下 emacs 配置，主要目的是提速 (各方面的)，emacs 从 27.2 升级到了 28.2 (眼馋 28 对 CJK 字符的 word-wrap 优化)。然后问题来了: htmlize 中的 org-html-htmlize-generate-css方法自 emacs 28.1 开始无法导出 emacs 的内部样式，emacs 28.2 official release 都有了，这个 bug 还没修。所以放弃使用 htmlize 的李守中重写了一下
org-html-src-block 这个负责导出 org file 中的代码块的函数，让最终得到的代码块可以被 highlight.js 渲染，接着用第一版的代码高亮方式。这就是第四版。(ps. 不用
prism.js 是因为，凭李守中的知识储备，适配 highlight.js 的工作量更小。)
第五版彻底解决了复杂排版的需求。因为后来 org mode 也不够翻译类文档排版用了。这个时候只能把排版交给 tex 了。但是除了对排版要求较高的翻译类文档之外，Markdown 足够普通文档用。所以李守中决定同时使用 Markdown 和 tex 格式来组织文档。
下面就是 tex 的选型了，由于 texinfo 是 GNU 官方支持的文档格式，再加上它有全面的导出格式支持 (HTML, PDF, TXT...)，还可以直接生成 .info 手册，在 Linux 上非常方便，所以李守中决定采用 texinfo 作为翻译类文档的源文件格式。但李守中没有 tex 基础，啃文档加迁移需要的时间有点长。在翻译类文档迁移到 tex 之前，翻译类文档会先被转成 Markdown 格式，通过混入 HTML 和 CSS 来完成复杂排版。迁移完成的 texinfo 文件会被 makeinfo 命令转成 HTML 文件，再通过静态页面引用的方式展现到浏览器上。
(翻译类文档源文件里几万字 Markdown 混合 HTML 和 CSS 的文本不仅不好读，还拖死了 vscode 的 markdown-lint 插件。但这只是一个临时的过渡方案，就不讲究那么多了。)
下一步就是决定怎么把这些 Markdown 文件转成 HTML + CSS 给读者看了。
用回 java 后台？现在服务器内存剩余不多了，再跑个 java 程序得升配置。加钱？那必不可能。用回第一版的 golang 后台？资源占用倒不大，但这一版后台的文章存储结构和 UI 都要重写，不 dei 劲。最好还是把站点静态化。用 hugo？可定义的东西太少，站内还想用 vue 做点在线工具用。查了一圈，发现 Astro https://github.com/withastro/astro 的 SSG 模式可以满足要求，同时支持独立引入 vue 来用，本站 工具 模块下的功能就是由 Astro 外挂 vue 做出的。
值得吐槽的是，Node.js 代码真是费内存，一个静态站生成器，总共才写了不到 1000 行代码，在 40 多秒的构建时间里吃掉 500M RAM... 啧，第二版整套 java 后台也没占这么多内存。看在它只在短暂的构建期间吃资源的份上，凑合用吧。所以，各位当前浏览的这个，用 Astro 生成的站点就是第五版。
本站页面由 Nginx 分发。SSL 证书由 acme.sh 管理。写好的文章通过 SFTP 上传到服务器，每天 4:00 (GMT+8) 定时更新。
这几次迭代导致了当前的站点结构简单地不能再简单，并没有什么很奇怪的操作和搭配。(所以老多人问这个有啥意义...)