2026-11-12 08:31:00
刚才本博客完成安装Debian 13.0，因为VPS提供的是这个版本。之前测试另一个VPS，服务商提供的版本是Debian 13.7。之后，在Debian 13.0系统下，安装的Apache、PHP的版本和Debian 13.7系统下完全一样，即Debian 13.0系统下安装的也是最新版本：Apache 2.4.69(2026年10月1日发布)，PHP 8.4.27。
这个例子，说明一个重要属性：Debian、Ubuntu系统下，同一主版本(例如Debian 12.X，12为主版本)，运行apt update这条命令之后，系统内置的软件仓，也会更新为最新版本。即Debian 13.0和Debian 13.7这2个系统，运行apt update之后，安装的Apache、Nginx、PHP等软件，版本都是分别完全一样的。
难怪在2019年时(前文链接)，Ubuntu 16.04自带的PHP是PHP 7.0，过段时间再安装，就变成PHP 7.3.9。当时感到非常不可思议。因为那时候Ubuntu 16.04是服务商提供的最高版本，想安装PHP 7.X，需要通过第三方软件仓安装的PHP。
不像现在的系统环境，安装PHP 7.X、PHP 8.X已经不需要第三方软件仓了，只需要用系统自带的软件仓，一个命令就全自动安装PHP 7.X、PHP 8.X：
apt -y install php
2026-11-11 18:27:00
网络重要资料： 1. 地漏断层该不该留？利弊全解析 (重做地漏的视频，断层害人害己) https://www.bilibili.com/video/BV11TYd6DEqY/
2. 那些说地漏一定要留断层的，不要再来出来祸害人了 (断层的危害之大) https://www.bilibili.com/video/BV1Ln1oBNE26/
2026-11-11 09:54:00
因为太辣眼睛，所以标题打了马赛克：判断瓦匠(瓦工)是不是缺德的方法。标准应该有很多，但今天要谈的一条金标准，就是有没有留“断层”。关于什么是断层，请在百度、或者bilibili.com搜索。我也是今天才知道有“断层”这个说法。断层，就是卫生间的地漏口，和下水孔对不齐，于是用了一种偷懒的办法，水会流到断层，然后再流到下水孔，后果很严重！
留断层就是缺德，而且是缺大德！他赌的就是绝大多数人不知道“断层”的危害。瓦工偷懒、偷工，因为能减少很多工时，但会造成周边的墙里全是水，甚至可能漏到楼下。断层，本来是不应该出现的。负责任的做法，是地漏和下水孔之间的这段距离，不能有水跑出来。断层，就等于是水会和墙面接触，后果是：
1. 断层周边的主要成分是沙子和水泥，由于水会流到断层，这里的水泥永远干不了，有一些水泥、沙子会流到下水道，并且恰恰在下水道的管道里凝固了，我家就是这种情况，好在流下去的水泥不多。
2. 更严重的后果是，水会从断层渗入墙体，和卫生间相邻的墙面，会起皮，我家就是这样。这说明，由于这个断层存在，经过1年～3年的时间，卫生间的瓷砖以下，全是水，周边的墙里也全是水，客厅的电视墙已经起皮好几年了(就是断层造成的)，在楼道外面看我家的墙，都能看到少量的水。
但好在卫生间的防水做得还是到位的，以前正好有事，我需要去楼下邻居家里，他家的房顶、墙没有漏水。
因为刚才看到超级维修达人(“超级”是因为他勇于分享看家本领) 老谢维修圈 的一条短视频，“断层修复器”。
从事维修的人，怎么会知道这么多的知识、经验呢？是因为客户找他们，这些知识、经验他们都是在维修、施工当中学会的。
断层怎么处理？
断层修复器，可能不适用于很大比例的家庭。正是因为地漏、下水孔之间的孔位不齐，才会产生断层的这种偷工的做法。
因为如果地漏、下水孔，是对齐的，就不会留断层，所以就不需要断层修复器。直桶断层修复器，也不适合地漏、下水孔错位的情况。
解决起来相当复杂，要么拆掉地漏整个重做、使之对齐、消除断层，要么想办法用软管。但是，用软管，就很难用防臭器，因为地漏和下水口之间的距离非常短。
为什么说这类瓦工缺德？
1. 因为装修，是全新装修，不是修补，所以想怎么做，就可以怎么做，绝对不存在地漏、下水孔之间的孔位不齐的问题，因为地漏的位置，可以随着下水孔来定，能定到100%对齐。
当时我家的瓦工，就是擅自做主，偷懒，擅自做了断层，没和我们说。可能是他想把地漏做得更漂亮一点，因为下水孔和墙面太近，大约不到3厘米、4厘米，他是为了地漏做成4面的方形图形，于是把地漏(水平方向)向下移了，导致地漏、下水孔的孔位不齐。
其实，如果当时他不留断层，反而简单。
2. 我家是2015年拆掉旧装修，重新装修的。这房子是我父亲的房子，2015年装修也是我父亲主持的，当时是我父亲和瓦工交接。
当时我对这位瓦工很礼貌、客气，理解他们体力的辛苦，一袋水泥还100斤呢，换来的是当时这位瓦工对我PUA。因为是给我家干活，也不好得罪他。都是以前自己从事的工作，长年是对着电脑，没有接触过多少现实社会的人性、素质。
以现在日益增多的见识到人性的经验，现在人家对我不客气，必须同样对对方不客气，而且给你的反应时间，只有3秒钟。
这里的bug就在于当时的装修不是我主持的，这位瓦工敢PUA我，要是换到现在，直接换人。
他的礼貌素质差，留的这个断层，更是缺大德。
他们2个人，当时给他们每人每天500元的工钱，9天的时间，共9000元工钱。工钱已经这么高了，还做如此缺德的事情。
堵漏王能不能解决断层？
不能，因为堵漏王凝固之后，还是怕水，会完全软化，然后流到管道，以前我试过。除了让地漏、下水口之间用管子衔接起来，也就是消除断层，基本上没有别的办法。
因为堵漏王怕水，所以堵漏王，还是属于断层。
只能寻找不怕水的胶，比如鱼缸用的玻璃胶这类，可能有效果。
网络重要资料
1. 地漏断层该不该留？利弊全解析 (重做地漏的视频，断层害人害己)
https://www.bilibili.com/video/BV11TYd6DEqY/
2. 那些说地漏一定要留断层的，不要再来出来祸害人了 (断层的危害之大)
2026-11-09 22:30:00
(网上也有很多人说Nginx支持，本文将会解释为什么不支持。) .htaccess网上的教程非常少，几乎接近于零。Nginx不支持.htaccess！不支持.htaccess，不支持.htaccess！重要的事情说3遍。Nginx的的确确不支持.htaccess！Nginx距离完美，就差这一步。本文是2016年时写的《Nginx与.htaccess》这一篇的延续，当时是想呼吁Nginx的开发方，能早日支持.htaccess，我马上就投奔Nginx。正是因为Nginx不支持.htaccess，所以我一直使用Apache。因为现在Nginx对http2、http3的支持非常好，更新很及时，Apache在http3的支持(自带模块)目前是完全没有(以2026年10月1日发布的最新版Apache 2.4.69，系统为Debian 13.7为例)。
.htaccess就是PHP的生命，主要是实现伪静态、临时修改Apache配置、php.ini配置等作用。.htaccess有多重要？本博客的语言现在是用PHP写的，正是使用.htaccess实现的改写扩展名为别的语言，比如能改成.jsp，.aspx，.html等任意扩展名，全站找不出一点PHP的痕迹。至少有4种方法能实现修改语言的扩展名，2021年时在这里公布了。巧合的是，今天引用的这2个旧链接，文章ID一个是888，一个是1888。这种巧合的概率是多少？为什么我今天会写这篇博客？(我最近完成的高防程序也必须用到.htaccess，绝对不能缺少，用于自动拦截很多非(隔开)法请求、空链接。)
网上也有很多人说，Nginx支持.htaccess，方法是在Nginx的配置文件/etc/nginx/nginx.conf里，写入这句：
include /var/www/html/abc.com/.htaccess;
然后在这个/var/www/html/abc.com/.htaccess的文件里，写入Rewrite，实现伪静态。
这也是网上唯一能找到的让Nginx支持.htaccess的方法。因为我隔一段时间，会关注Nginx有没有推出支持.htaccess的功能。
非常遗憾，这并不是真正的支持.htaccess，而是Nginx支持在配置文件里使用include语句。此时，如果把这个.htaccess更改为别的任意文件名，也一样能正常运行，例如abc.conf，那么相应的include语句是：
include /var/www/html/abc.com/abc.conf;
这只能说明Nginx的配置文件支持include，实质并不支持.htaccess。
怎样才是真正的支持.htaccess？
就是在配置文件里，不需要写入这句include语句，而在站点建立.htaccess文件，此时.htaccess文件里写入的语句，会生效。
Apache的.htaccess文件，就是这样工作的，不需要在配置文件里写入include语句，直接在站点建立.htaccess文件即可。
Apache的.htaccess文件，有个很大的特性，就是会对当前的目录、以及当前目录下的所有子目录生效。
例如：
1. 在站点的根目录下，建立abc.com/.htaccess，这个.htaccess会对整个站点的根目录、以及所有子目录起作用。
2. 在站点的二级目录，建立abc.com/folder1/.htaccess，这个文件会对abc.com/folder1目录、以及abc.com/folder1下的所有子目录起作用。同时，第1步在网站根目录下建立的.htaccess，也会对abc.com/folder1下的所有子目录起作用。
如果这2个.htaccess文件里写入了相同的指令，会优先执行abc.com/folder1/.htaccess这个文件里的配置。
Nginx的.htaccess，和Apache的.htaccess，有什么不同？
Apache在非常早的版本，就支持.htaccess。我是在2009年时，学会的PHP，那个时候的Apache就支持.htaccess。
到了2026年，Nginx至今仍然不支持.htaccess。
我是怎样学会使用.htaccess的？是因为底层需求：伪静态。网上的教程非常少，几乎接近于0。
因为在200X年的那个时代，所有的动态网页，扩展名都是.asp，.php，中国的互联网上只有这2种语言。到了2003年～2005年，中文有了博客，那时候已经有博主会使用伪静态，非常酷！
能把一个abc.php?id=1233转化为abc/1233.htm，或者abc/1233这样的链接，这就是伪静态。
实现伪静态的方法，主要有2种，目前到了2026年，绝大多数博客都是使用Rewrite；另一种是404错误页，用header('HTTP/1.1 200 OK')语句改为200代码，这种方法已经几乎彻底失传，我一直是用这个方法，因为404错误能节省一个Rewrite模块。
这种404错误页的方法，我当时是从plod.popoever.com的博主学习到的，整个互联网只有他分享过这个方法，记得好像他是在蓝色理想的论坛里分享的。
Nginx的.htaccess，和Apache的.htaccess，有什么不同？
1. Nginx的.htaccess，是强行把一个配置文件改名为.htaccess，然后在Nginx的配置文件里用include，来包含这个文件。
Nginx的这个方法，等效于把.htaccess文件里的内容，写入到Nginx的配置文件，是对整个站点的所有目录有效，属于全局设置，会占资源。
2. Apache的.htaccess，可以设置对整个站点的所有目录有效，属于全局设置；也可以只单独对一个目录有效，方法是把.htaccess文件放在子目录里，属于局部设置。
简言之，Nginx强行建立的.htaccess文件，只能建一个(当然，也可以同时include多个文件，但本质上include多个文件就等于include一个文件，因为include等效于把include文件里的内容，写入到Nginx的配置文件)；Apache可以建立无限个.htaccess文件。
为什么Nginx不支持.htaccess？
网上有一种说法是由于Apache的.htaccess文件，会对整个站点起作用，会占资源。其实，确实会对整个站点起作用，但那是网站根目录的.htaccess文件。
Apache完全可以解决这个问题，就是网站根目录的.htaccess文件，控制语句要尽量少写。Rewrite语句，或者404错误页语句，在相应的二级目录、或三级目录建立.htaccess文件。
.htaccess这么重要的作用，Nginx不支持，大概的原因有这2个：
1. 开发者把所有的Rewrite语句写入到Nginx的配置文件，或者使用include的方法。include等效于直接写在配置文件。
2. 尽管Nginx已经发展为伟大的服务器后台，Nginx的开发者本人，也可能尚未使用过Apache的.htaccess功能，造成了关键信息衔接不足。因为会使用Apache的.htaccess的人，非常少，只是某个时间段，在网络上流行了一阵，这个时间段大约在2008年～2011年，其余的时段都是失传的。
从Nginx的404错误页的PHP文件用header('HTTP/1.1 200 OK')改为200代码，会跳转到404错误网页，就能看出来，Nginx的开发者尚未使用过Apache的.htaccess功能，而是在Apache的配置文件里写Rewrite。因为Apache的404错误页，不会跳转，我就是用Apache的.htaccess的404错误页，实现所有的伪静态。
假如将来Nginx能够支持.htaccess，且.htaccess指定的404错误页不会跳转到404错误网页，并不存在模仿，而是基本的技术需求，这2条，Apache都是完美支持的。
2026-11-08 20:45:00
毫无悬念，是李嘉欣，是女华人颜值的天花板。她不但漂亮，而且全方位无死角，无论是任何时期、任何角度，李嘉欣都会让人眼前一亮。但是，最近发现一个现象，现在短视频里有很多漂亮的90后、00后主播，以及70后～90后的明星，有时候也说不清她究竟哪里漂亮，其实有一种类型，有20%～30%像李嘉欣，像某个时期的李嘉欣。
女歌手里，颜值的天花板基本上是陈慧琳、张靓颖(刷到陈慧琳最新颜值视频，请看截图)；邓紫棋的颜值，其实可能被严重低估，邓紫棋是一种后天努力美。我是陈慧琳的铁杆歌迷，陈慧琳1995年的首张专辑《仙乐飘飘》和1996年第2张专辑《风花雪》我当时都有收藏。她最好听的歌是《风花雪》专辑里的《谁愿放手》，以及后来的《撩我》，2008演唱会的《伶仃》(35岁时)。她的声音独特，清亮、具有穿透力、风格多变，2008演唱会把这种清亮发挥到极致。歌词含义最好的是《谁愿放手》，令人回味无穷。
关于张靓颖
张靓颖之前已经点评过了，就不重复了，人美歌美，前文链接。
张靓颖2011演唱会版的《我们都辜负了爱》《G大调的悲伤》《个人秘密》，是我无限循环的歌。她的歌声，能够清晰地表达歌曲里的感情，又富含现代欧美流行唱法。
不需要听艾薇儿，只需要听张靓颖。
关于邓紫棋
邓紫棋是华人女歌手的票房冠军，超越麦当娜，成为全球史上票房第4高的女性艺人巡演。邓紫棋的《I AM GLORIA》世界巡回演唱会，创造了30.4亿人民币的票房。
虽然我听她的歌不多，还没来得及听，她那首很燃的欧美风格《来自天堂的魔鬼》是我女儿喜欢听的，之后我也经常听这首歌。
这首歌不仅是因为她深厚的唱功，作曲、编曲、配乐方面都达到很高的精致水准。
关于邓紫棋的颜值
邓紫棋第一眼可能不会让人眼前一亮，她的美是因为工作上的努力，这种美也能让人成为顶级颜值。因为没有人天生就很会唱歌，大多数的巨星都需要花很多的时间独自练歌。唱得好，就是努力的体现。
之所以我会关注邓紫棋，是因为我见过一个工作很努力的一个人，染金色的头发，背影和邓紫棋一样。
2026-11-08 08:29:00
(本文含Debian 13的小bug；Let's Encrypt只能建1个https站点的严重基础bug和解决办法，请见本文最后) http3确实很有可能性能比http高。https是2018年互联网环境开始强推的模式，计划2026年10月某浏览器会对http进行页面阻拦。到了这个时间，如果不安装https，网站的流量会越来越少，环境强推所致。昨天进行测试http3，安装VPS供应商的Debian 13，安装完成之后，查看版本是Debian 13.7，这个系统是2026年9月12日发布的。
Debian 13.7比想象中好很多，仍然是节省内存(Debian比Ubuntu节省内存)。1G的内存，安装Apache、PHP 7/8之后，重启系统，Debian 11.1(PHP 7.4.33)剩余838420 KB(818.77 MB)，Debian 12.0(PHP 8.2.32)剩余795080 KB(776.45 MB)，Debian 13.7(PHP 8.4.27)剩余810580 KB(791.58 MB)。Debian 13.7，反而比Debian 12.0，节省15 MB的内存。
由于需要测试、加强PHP安全，我现在的5台VPS，安装的系统版本分别是：
Debian 11.1
Debian 12.0
Debian 13.7
Ubuntu 14.04 (2台，当时因为工作太忙，所以全都临时安装Ubuntu 14，因为当时自开发的一键安装命令只剩Ubuntu 14。)
Debian 13.7默认的PHP安装源是PHP 8.4.27，这个PHP 8.4.27正好在最近的0day漏洞的修复名单。
之后安装Let's Encrypt，命令可以在网上搜索。在安装Let's Encrypt之前，一定要先在Apache或Nginx的配置文件里建好站点。我使用的是Apache，相应的命名是：
apt -y install certbot python3-certbot-apache
certbot --apache
如何查看是否支持http3？Let's Encrypt是否支持http3？
安装好Let's Encrypt，或者自签名SSL之后，使用Firefox访问自己的站点。按F12，选择“网络”的标签，然后再按F5刷新一下网页，在网址列表里，找到当前网页的文件(因为列表里有很多JS、图片、CSS的元素)，点击之后，在右边可以看到网页的属性，是不是HTTP/1.1、HTTP/2、HTTP/3。
但很遗憾，目前最新的Debian 13.7，使用Let's Encrypt默认的官方安装命令，安装的https，仍然是HTTP/1.1。
我看了一下很多独立博客，大部分都是HTTP/2，极少部分是HTTP/3。
测试的结果，Debian 13.7内置的SSL程序，没有支持http3；Let's Encrypt的安装包里也没有内置支持http3。
http3需要额外手动安装，依赖包相当多，到这一步我已经放弃了。
Let's Encrypt当前的一个严重基础bug：只能建1个https站点
做程序开发的时间越长，你越会发现，“这世界是个巨大的草台班子”是实实在在的一个巨大真理，并非玩笑，这是因为部门之间的信息衔接不足，导致关键的地方出现bug，却无人处理。
和这句话同级别的巨大真理，还有一些，我最近思考了很多天，现在开始在笔记里整理这些人们发现的巨大型真理。因为这种巨大型真理，能让人的人生少走很久弯路。
这个严重的基础bug，是Apache下，安装Let's Encrypt，只能安装一个域名的SSL，我在Debian 11、Debian 12、Debian 13下安装Let's Encrypt，都是这个问题。
Nginx下，有可能不存在这个bug。因为我的服务器后台都是使用Apache，暂时没条件(时间)测试Nginx。现在绝大多数的博客，都是Nginx，几乎没有多少人使用Apache。
(很多人使用Nginx，是因为Nginx宣传中的并发数比Apache高很多。其实，PHP的瓶颈在于MySQL，由于Nginx不像Apache原生支持.htaccess，导致我只能选择Apache。)
因为使用Apache的人很少，导致这个基础bug出现。
昨天终于找到这个bug的原因。Let's Encrypt的站点配置文件，路径是/etc/apache2/sites-enabled/apache2-le-ssl.conf。
Let's Encrypt的bug如：
当给站点1建立SSL之后，站点1可以用https正常访问，SSL证书正常。
当给站点2建立SSL之后，站点2可以用https正常访问，此时站点1则变成自签名SSL，出现页面拦截。
再用安装命令，重装安装站点1，会出现选择，“是否尝试修复”，选这一项，之后站点1可以用https正常访问，站点2却又变成自签名SSL、页面拦截。
之后查看apache2-le-ssl.conf这个文件。bug的原因是出在这里，其实站点1和站点2的证书文件都已经安装正确、安装完成。
bug的原因是Let's Encrypt的开发人员，对apache2-le-ssl.conf这个文件的写入出现设计错误，里面的配置是张冠李戴。
正确的站点配置是站点1、站点2。而现在的apache2-le-ssl.conf，站点1的配置是站点1的站点路径，证书文件却是站点2的证书文件；在apache2-le-ssl.conf文件里，站点2却又变成80端口。
这种张冠李戴的现象，是因为开发人员没有进一步测试。他安装完一个站点，就停止测试了。
解决的办法：
1. 重装安装Debian、Ubuntu系统、Apache/Nginx、PHP，使配置文件处于干净状态。
2. 先建立80端口的站点，否则无法被Let's Encrypt识别。
3. 安装Let's Encrypt第1个站点。之后，立刻备份/etc/apache2/sites-enabled/apache2-le-ssl.conf文件，命名为apache2-le-ssl.conf2，查看他的SSL站点的标准配置。
4. 安装Let's Encrypt第2个站点。这时候会发现apache2-le-ssl.conf文件，站点的配置已经张冠李戴，完全错乱了。
5. 打开刚才的备份文件apache2-le-ssl.conf2，把站点1的配置复制一遍，并把新复制的内容的域名改为站点2，然后粘贴到这个文件。
之后把apache2-le-ssl.conf2改名为apache2-le-ssl.conf，替换已有的文件，重启Apache，这时候站点1、站点2、站点3……就都能支持https了。
Debian 13的小bug
我使用的VPS，现在是2家供应商。之前测试，同样是Debian 11，替换为相同的软件源，/etc/apt/sources.list这个文件，安装之后，系统环境也不一样，比如有一家VPS，默认自带sudoers、iptables，另一家VPS则不自带sudoers、iptables，需要手动安装。
现在使用的这家VPS供应商，Debian 13.7不自带sudoers、iptables，而且连wget都不自带。这3个都需要手动安装，安装命令也十分简单：
apt -y install sudo
apt -y install iptables
apt -y install wget
https的速度
Debian 11/12/13+Let's Encrypt，安装的https默认是HTTP/1.1，速度比http模式慢，之前的https测速，就是HTTP/1.1模式下的https。
http延迟平均0.39毫秒～1.2毫秒，HTTP/1.1模式的https的延迟平均在6.3毫秒～25毫秒，更多是集中在12毫秒～16毫秒。
现在安装https是一种受罪，将来还可能会全面收费。过渡期，只能暂时这样。安装https唯一的好处是浏览器不会出现“不安全”的警报，现在浏览器进一步强推，已经计划对http页进行页面拦截。
