这个页面也集中回答邮箱收到的，被问了很多次的问题。
很多读者找到这里是为了看李守中翻译的文档。为了方便读者，李守中单开了一个 翻译模块，读者可以从页面顶部进入。
该站点为李守中 (联系方式: 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？值得考虑，但李守中没有 tex 基础，啃下它来还要些时间。突然，李守中意识到 Markdown 内可以混入 html 和 css 代码来影响页面的最终显示效果。所以，所有文章又被改回了 .md 格式，需要特殊排版的地方就手写 HTML 和 CSS。兜了个大圏又回来了。看着几万字 Markdown 混 HTML 和 CSS 的文本，都把李守中自己丑到了。其实第五版站点重建的一开始，李守中想把文档转 texinfo 格式，但啃文档加重写需要的时间有点长。先用这种丑陋的写法凑合着吧，慢慢把文章往 texinfo 迁。下一步就是决定怎么把这些丑陋的 Markdown 文件转成 HTML + CSS 给读者看了。
用回 java 后台？现在的服务器内存剩余不多了，再跑个 java 程序得升配置。加钱？那必不可能。用回第一版的 golang 后台？资源占用倒不大，但这一版后台的文章存储结构和UI 都要重写，不 dei 劲。最好还是把站点静态化。用 hugo？可定义的东西太少。站内还想用 vue 做点在线工具用。查了一圈，发现 Astro https://github.com/withastro/astro?tab=readme-ov-file 的 SSG 模式可以满足要求，同时支持独立引入 vue 来用，本站 工具 模块下的功能就是由 Astro 外挂 vue 做出的。
值得吐槽的是，Node.js 代码真是费内存，一个静态站生成器，总共才写了不到 1000 行代码，在 40 多秒的构建时间里吃掉 500M RAM... 啧，第二版 java 后台也没占这么多内存。看在它只在短暂的构建期间吃资源的份上，凑合用吧。所以，各位当前浏览的这个，用Astro 生成的站点就是第五版。
本站页面由 Nginx 分发。SSL 证书由 acme.sh 管理。写好的文章通过 SFTP 上传到服务器，每天 4:00 (GMT+8) 定时更新。
这几次迭代导致了当前的站点结构简单地不能再简单，并没有什么很奇怪的操作和搭配。(所以老多人问这个有啥意义...)