2025-10-07 18:29:35
国庆第一天，刚处理了国内的阿里云个人博客服务器被刷爆带宽。 而国庆第五天，一大早就收到海外的一个网站服务器（Linode Server）的宕机通知邮件。
早上一起床就赶紧登上了服务器，发现是网站服务器被刷流量，直接导致服务器负载过高，网站无法访问。
几乎全部的垃圾流量都是在刷一个站的博客列表页面，路径如下：
/latest-blog?mdrv=<xxx.com>&start=<random_number>
/latest-blog?=1&pagespeed=%27%3Fpagespeed%3D%27&start=2750
请求大概一秒钟几十次，一直在持续，没有停下来的意思。 观察了两天，攻击流量在减少，但是还没有停止。至少服务器负载降下来了。
让 DeepSeek 帮忙分析了一下，给出了两个屏蔽规则:
location / {
# 匹配 /latest-blog 路径且 mdrv 参数值包含 .com
if ($request_uri ~* "^/latest-blog\?.*mdrv=[^&]*\.com") {
return 444;
}
# 新增规则2：屏蔽 /latest-blog 路径且包含 pagespeed 参数（不区分大小写）
if ($request_uri ~* "^/latest-blog\?.*pagespeed") {
return 444;
}
try_files $uri $uri/ /index.php?$args;
}
AI 非常适合写正则表达式，反正比我写的好。
整理这篇文章，主要是为了记录 Nginx 的配置。
这个网站是一个 PHP Joomla 搭建的内容站。（Joomla 类似 WordPress）
我的体会是，通用的 php 建站系统，类似 WordPress、joomla、magento 为了通用性，页面请求的处理逻辑包含了大量的数据库联表查询。
导致一个 4 核 8G 的服务器，连处理一秒钟 100 次的请求都吃力。 而且要去做定制化缓存，也非常麻烦。
这两天刚听了 Ruby on Rails 作者的一个播客，他承认 Ruby 哪里都好，就是服务器需要多一点的成本。 PHP 也是类似的道理。我还是更喜欢 Go 来开发网站，至少不用为了性能去折腾。也能扛住这种小规模的攻击。
自己开发，也可以在参数中增加校验，例如页面参数，再增加一个校验串，防止随机页码。
这个网站比较特殊，主站使用了 Cloudflare，但是为了自动支持多语言，使用了三方的翻译服务。 相当于几十种翻译，每个语种对应一个新的二级域名，每个二级域名需要解析到三方的实时翻译服务上，三方翻译服务收到正常用户的请求后，拉取对应的源站内容，实时翻译为目标语言，再返回给浏览器用户。由于需要加三方翻译服务的 IP 白名单，导致 cloudflare 的拦截失效。
而 Cloudflare 是可以识别这类攻击，自动返回 robot challenge 页面，防止恶意流量的。
前两天发的那篇国内服务器被刷流量的公众号文章，有个专业做 CDN 的大佬恰好刷到了，就加了我微信， 推荐了他们的 CDN 服务，蓝易云，官方地址：
处理机制也跟 cloudflare 类似，在识别出攻击流量特征后，触发强制人机验证。 而且他们也遇到了国内广东大量 PCDN 刷流量的问题，也做了相应的防护。跟这位大佬交流的过程中，感觉还是专业的 CDN 服务靠谱一些，我这种个人开发者，还是不要自己折腾了。 蓝易云也有海外的 CDN 节点，可以考虑使用。
感兴趣的兄弟可以加这位大佬的 V：lanyiyun6
2025-09-29 16:07:46
开发完了公司内网的人事管理系统，开始动手测试，发现里面的测试数据惨不忍睹，全是 111，222 这样的名字，员工资料里全是数字，显得系统异常粗糙😵💫。明天就要给人事部门演示了，这样可不行。于是我就用之前开发的 随机生成身份证号，手机号，邮箱地址的微信小程序 生成了一堆测试数据，界面里面看起来像个正式一点的人事系统了。但是，还有一部分数据没法自动生成，例如，家庭住址/户籍地址，工作单位，职务这些信息。
于是，我想干脆借此机会把这个工具再完善一下，就加上了更多的个人资料字段随机生成，效果如下：
本来想加上一些工资卡开户银行的信息想想算了，怕引起敏感词问题。同时增加了网页版本，方便在不方便登录微信的办公机上使用🤣🤣🤣 网页版地址如下：
https://www.sunzhongwei.com/tools5/random-person-info
但是手动复制的效率还是低，要录入几十个员工的测试数据，还是一件异常繁琐的体力活。我要试试微软新开源的 playwright 自动化测试工具，通过调用我的这个网页接口来获取数据，然后填充到页面中。直接插入数据库不好吗？我感觉还是不如在界面中操作更容易发现问题。再就是不知道 playwright 如果接入 mcp 会不会更简单一些。
尝试了一下 gpt5 codex 的代码效果，还可以，就是有点发挥不稳定的感觉。有时候很聪明，有时候又智障的不行。但是实现这种简单的随机数据，还是很适合的👍
2025-09-21 15:22:39
今天在排查一处程序 bug 时，发现一段代码写的逻辑实在乱，完全没有印象正确的逻辑应该是怎样的。 于是想查看这段代码是不是自己写的，什么时候写的，为什么这么写的。
直接在 VSCode 的 github copilot 的 Chat 窗口中问了一下：
如何通过 git 命令查看某段代码是那个提交修改的：例如：
line1
line2
line3
得到的回答是，可以试试 git blame 命令。试了一下，非常好用。
例如, 我想查看 models/product.go 文件中第 10 到 13 行的修改记录，可以运行：
git blame -L 10,13 models/product.go
执行结果如下图：
可以看到每一行代码前面都有一个 commit hash 和作者信息。通过这些 hash 可以进一步查看具体的提交内容。
git show <commit-hash>
网上搜索了一下，发现 VSCode 内置了 git blame 功能，可以直接在编辑器中查看每行代码的最后修改信息。
参考，VSCode 的官方文档：
https://code.visualstudio.com/docs/sourcecontrol/overview
可以看到，编辑区域的底部的 Status Bar 上会显示当前行的最后修改信息，点击可以查看更多详情。如下图所示：
还是 VSCode 方便啊。
2025-09-17 17:19:44
最近批量导入了一批 Magento 产品信息，不知道为何直接导致服务器磁盘空间被占满。 而导入的产品也不多，不到1万个，理论上不应该占用上 G 的空间啊。
使用之前的磁盘空间分析工具 ncdu。使用方式参考： 使用 ncdu 命令分析 linux 磁盘空间占用
发现，最占磁盘空间是 Magento 的项目目录。占了 76 G。
然后，在结果里面逐级进入子目录，发现最占空间的 Magento 子目录是：
pub/media/catalog/product/cache
占了 56 个G。这个目录里全部是产品图片的缓存，即各种尺寸的缩略图。
不得不说，ncdu 真是运维神奇啊。
比较诡异的是，进入 pub/media/catalog/product/cache 下面的最终子目录，会看到很多同名的图片文件，只是数字后缀不同。 例如：
从文件大小看，是完全一样的大小，推测就是同一张图片的多个拷贝。从浏览器链接访问，发现确实都是一样的图片。
那么，为什么会有这么多同一张图片的拷贝呢？估计是批量导入时，很多产品的图片是相同的，导致 Magento 生成了很多重复的缓存图片。 但是，就算是这样，也不应该占用这么多空间啊。
完全一样的问题，而且版本也对的上。有人反馈 2.4.6 也遇到了。
其中一个解决方案，就是禁用 CSP 模块。
如果不了解什么是 CSP，可以参考：开源商城系统 Magento 修改 Content Security Policy (CSP) 配置，添加新域名白名单
Content Security Policy 是一种安全机制，旨在减少跨站脚本攻击 (XSS) 的风险。
CSP 就是个 js 白名单功能，我感觉跟 cache 没有任何关系。。。但是这两个讨论里都说有效。
Thanks for all the feed-back. I can confirm to you that disabling Magento_Csp module resolved the issue on Magento 2.4.1 version I have. My cache only grew to 600MB and is stable now compared to multiple GB previous days. This is inline with my experience on Magento 2.3.3. Thanks for the help and prompt feed-back. I really appreciate it!!!
禁用命令：
php bin/magento module:disable Magento_Csp
然后清理缓存：
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f
php bin/magento cache:flush
因为只剩下 100M 的空间了，不得已，只能先删除图片缓存目录。 从 Magento 管理后台操作就行：
System -> Cache Management -> Flush Catalog Images Cache (页面最底部)
然后，再点击右上角的 Flush Magento Cache 按钮。
一顿操作之后，磁盘空间终于释放了 70G。
只能观察一天了，看看图片缓存还会不会继续增长。
从 Magento Github Issue 的讨论来看，Magento 的官方开发团队确实不太行。 很多问题，拖了几年都没有解决。而且性能还这么差，确实复杂的系统，维护成本太高了。
2025-09-15 20:02:48
每个周写周报是最浪费生命的事情之一，之前就吐槽过一次。本来是部门范围内提交就可以了，现在变成了公司所有人都需要提交，还要抄送人事部门，保证人事部门的 HR 也能看懂 🥲 这就很头疼，比如花费了一天时间完成了复杂的文件资料管理功能，但是提现在周报里就是一句话“实现了文件资料管理接口”。看起来没啥工作量的感觉 😅 比起写周报，还是写代码简单快乐一点。
今天周一，傍晚临下班提交 git commit 时，准备顺便把提交内容复制一份到周报文件里，这样就能省去周五下午花时间再整理。突然想到，为何不能让 ai 根据 git 提交历史信息自动生成周报呢🤔 great idea！于是动手试验了一下，效果非常满意👍
vscode 的 GitHub copilot chat 窗口中输入以下提示词。注意要在 agent 模式下执行
基于上周的 git 提交历史，帮我生成周报。文字控制在 300 字以内，最好人事部门的 HR 能看懂
会看到 copilot 会自动执行 git log 命令查看历史记录，并限定了时间范围。以下是 auto 模式下的生成效果，我看了一下，可能是我的付费模型配额充足，所以自动使用了 claude 4 模型。效果确实比 gpt 4.1 要好太多，有组织，有逻辑，而且还有唬人的牛马汇报词汇🥲
_1757937753.webp)
而实际的 git log，朴素的不能再朴素，完全跟上面的 ai 生成的周报不搭边。要是我跟 ai 是同事，干一样的活，优秀员工肯定是 ai 的了 🥲
有了这个周报生成大法，就不再需要额外花时间去组织周报内容了。把提示词一复制，1分钟搞定。本来就没有人认真看的东西，生成的玄乎一点挺好，而且也不是凭空捏造的工作内容，只是换了一种高大上的表述方式。
唯一麻烦的地方是，如果并行开发多个项目，得限制一下 ai 的发挥，控制每个项目的汇报篇幅。
还有一点比较好，还能根据我的项目 todo markdown 文档，自动生成下周计划，哈哈。真的像是有了一个全能的小秘书。
2025-09-13 09:59:58
找了半天 Magento 无法批量导入的问题，最后发现是 crontab 里设置了一个定时任务，每半小时 restart php fpm 的 docker 容器。导致 Magento 的批量任务没有执行完，就被 restart 中断了。如此反复，导致没有一个批量任务导入成功的。 我在 Magento 日志中，没有找到任何的相关日志，完全靠翻看数据库表结构，盲猜 magento 的导入机制，才解决这个问题的。
记录一下排查中学到的 Magento 无用知识：
有个数据表，名为 importexport_importdata，记录了需要导入的产品信息。
实际数据来源就是，后台上传的 csv 文件。
magento 会默认按照 100 个产品为一组，作为一条记录。记录值为一段 json。
这个切分单位 100 是可以通过配置文件修改的。
CREATE TABLE `importexport_importdata` (
`id` int UNSIGNED NOT NULL COMMENT 'ID',
`entity` varchar(50) NOT NULL COMMENT 'Entity',
`behavior` varchar(10) NOT NULL DEFAULT 'append' COMMENT 'Behavior',
`data` longtext COMMENT 'Data',
`is_processed` tinyint(1) NOT NULL DEFAULT '1' COMMENT 'Is Row Processed',
`updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'timestamp of last update'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COMMENT='Import Data Table';
数据示例
INSERT INTO `importexport_importdata` (`id`, `entity`, `behavior`, `data`, `is_processed`, `updated_at`) VALUES
(868, 'catalog_product', 'append', '{\"0\":{\"sku\":\"M3AA-90LD-4\", ... }', 0, '2025-09-12 21:32:33');
直接清空这个 importexport_importdata 表即可。
注意，最好不要使用 truncate，最好使用 delete。因为 truncate 会导致自增 id 被重置从 1 开始。不确定是否有其他表关联了这个 id，所以使用 delete 保险一点。
如果在 magento 后台，批量导入的 csv 中包含数量巨大的产品。例如，超过 1000 个。大概率会遇到一直转圈处理中的提示。从浏览器调试工具看，查询进度的请求报了 524 错误。这是一个 cloudflare 的超时状态码。
其实，只要 csv 的里的产品数据，被存储到了导入队列表，那就可以关闭 magento 后台网页，甚至关闭浏览器。等待处理完成即可。
观察了一下 magento 的导入队列处理过程。发现，并不是顺序处理的。即不是按照 id 从小到大逐一处理的。从导入数据看，会同时导入前面几条记录中的产品信息（通过 SKU 搜索来排查）。
而且，导入是否成功的状态，是按照队列记录来的，而不是单个独立产品。所以，我猜测，这个队列处理机制是，定时任务处理队列记录，取出一条记录，解析出来产品列表，逐一保存。如果一条队列记录的处理被打断，例如运行时间过长，下次会从头重新处理。
比较诡异的是，这个处理是否完成，是批量同时更新的。例如，一批 2000 个产品，被分割成了 20 条处理记录。处理完成时间是一样的。。。而不是逐个完成。
从产品的创建时间看，写入数据库是实时的，但是不能及时在后台产品列表中看到产品。猜测是索引数据需要时间，有较长的滞后性，不知道创建索引是否也是以 100 为单位批量进行的。
整体感觉 magento 的代码质量不太行，例如这个批量导入的体验极差
我可以通过程序直接插入这个 mysql 表，importexport_importdata，就绕过了完全没有头绪的 magento php 接口，来实现批量导入。
得测试一下看看可行性如何。
