2026-10-22 10:28:44
现在每年的各种电商平台的狂欢节，什么618，双11双12之类的，感觉不温不火的，甚至连广告都看不到。
当然，可能这也是个性化广告的最终效果吧，知道我买不起，就干脆连广告都不给推了。虽然广告没怎么看到，但是为了凑满减，还是买了一堆东西。
这一堆满减折扣，也不知道是真的还是假的，多数应该是真的能便宜点吧，哪怕折扣之前稍微提价了。在这之前也买了一些东西，两条裤子，还有一些其他的乱七八糟的东西。
这不温不火的活动，还不如it行业这突如其来的php的两个漏洞激起的水花大。连高市都发了修复的推文：
几台服务器，虽然用php的不多，但是当时为了快速部署，用的lnmp的一键部署脚本，顺便就把php给一块搞进去了，还是个7.4的版本。现在连lnmp官网的下载安装脚本都挂了，那就更不可能通过脚本进行php升级了，这也是为什么工控机上的php就停留在了7.4。虽然后来装了个8.1却始终没有切换。好在现在有了功能强大的ai，直接让ai进去一通乱搞就修复好了。之前之所以没有升级还有个更大的问题就是分词组件不支持php8，mac上的分词功能已经独立出来了，工控机上的没有处理，所以后来就成了这个状况。mac上的php早上直接通过apt升级了，能apt搞的确要方便很多，毕竟编一个php得跑半天。ecs上也有几台跑着php虽然没有php的业务，但是进行依然在运行，直接停止禁止自启算是解决了php的问题。技术依赖果然不是什么好习惯，装的时候省事，等出问题的时候，修复就贼拉麻烦，早晚得有拉清单的时候。
lighthouse@VM-16-8-ubuntu:~$ ps aux | grep php root 861 0.0 0.4 88340 15876 ? Ss 2024 31:43 php-fpm: master process (/usr/local/php/etc/php-fpm.conf) www 2039 0.0 0.7 101528 26680 ? S 2024 0:31 php-fpm: pool www www 2040 0.0 0.7 101528 25056 ? S 2024 0:31 php-fpm: pool www www 2041 0.0 0.5 95524 20640 ? S 2024 0:31 php-fpm: pool www www 2042 0.0 0.6 95384 20920 ? S 2024 0:31 php-fpm: pool www www 2043 0.0 0.7 101528 24744 ? S 2024 0:31 php-fpm: pool www www 2044 0.0 0.7 101660 26652 ? S 2024 0:31 php-fpm: pool www www 2045 0.0 0.7 101528 26780 ? S 2024 0:31 php-fpm: pool www www 2046 0.0 0.7 101528 26908 ? S 2024 0:31 php-fpm: pool www www 2047 0.0 0.7 101528 27164 ? S 2024 0:31 php-fpm: pool www www 2048 0.0 0.7 101528 26620 ? S 2024 0:31 php-fpm: pool www www 2049 0.0 0.7 101528 26672 ? S 2024 0:31 php-fpm: pool www www 2051 0.0 0.7 101528 27172 ? S 2024 0:31 php-fpm: pool www www 2052 0.0 0.7 101664 26872 ? S 2024 0:31 php-fpm: pool www www 2053 0.0 0.7 101664 26904 ? S 2024 0:31 php-fpm: pool www www 2054 0.0 0.7 101528 26832 ? S 2024 0:31 php-fpm: pool www www 2055 0.0 0.7 101528 27320 ? S 2024 0:31 php-fpm: pool www www 2057 0.0 0.7 101532 26908 ? S 2024 0:31 php-fpm: pool www www 2058 0.0 0.7 101664 26884 ? S 2024 0:31 php-fpm: pool www www 2061 0.0 0.7 101532 26960 ? S 2024 0:31 php-fpm: pool www www 2063 0.0 0.7 101532 26960 ? S 2024 0:31 php-fpm: pool www lightho+ 1609805 0.0 0.0 6612 2292 pts/5 R+ 10:09 0:00 grep --color=auto php www 3868312 0.0 0.5 95388 20884 ? S 2024 0:31 php-fpm: pool www lighthouse@VM-16-8-ubuntu:~$ sudo lnmp php-fpm stop +-------------------------------------------+ | Manager for LNMP, Written by Licess | +-------------------------------------------+ | https://lnmp.org | +-------------------------------------------+ Gracefully shutting down php-fpm . done lighthouse@VM-16-8-ubuntu:~$ sudo systemctl stop php-fpm lighthouse@VM-16-8-ubuntu:~$ sudo systemctl disable php-fpm Synchronizing state of php-fpm.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable php-fpm Removed /etc/systemd/system/multi-user.target.wants/php-fpm.service. lighthouse@VM-16-8-ubuntu:~$ ps aux | grep php lightho+ 1610176 0.0 0.0 6480 2304 pts/5 S+ 10:10 0:00 grep --color=auto php lighthouse@VM-16-8-ubuntu:~$
还是不能偷懒，都不用php，干嘛要偷懒用什么一键安装工具装这些乱七八糟的东西呢~~
除了php，连nodejs以及阿三签发的证书也出来凑热闹了，挺安全的一套加密系统，印度阿三能用个4作为密钥。这也算是符合印度阿三的人设了，毕竟泄露点苹果的资料啊什么的都是常规操作了。
2026-10-19 14:47:49
今天早上收到uniapp云空间续费的通知，看了下还有一个月到期，点击续费的时候发现最长时间选不到一年了。
看了半天才注意到底下那张字：
因阿里云 EMAS 功能逐步下线，uniCloud阿里云服务空间自2026年11月1日起不再支持新建，并将于2027年9月30日正式停服，续费后的到期时间不得晚于2027年8月31日，建议您尽快迁移，
一句话总结，就是阿里云的空间续费不了了，只能换其他的。甚至还贴心的给出了迁移工具，
这个东西聊胜于无，有总比没有要好一些。然而，及时是如此还得面临一系列的问题，域名不能同时存在，如果要想业务不中断就得先发布版本替换线上使用的域名，切换到新域名。无形中增加了app和服务的运维成本。
后面几个app的推送也用的unicloud的云空间，不过这次没有再使用uniadmin之类的面板也没有再为每个app创建独立的云空间。将多个app绑定到了同一个空间，毕竟这些app使用的功能也只有消息推送而已，完全没必要每个再创建一个独立的空间。毕竟dcloud提供一个免费的空间，剩下的都得花钱购买了，免费的先用着也不是不可。
新空间是支付宝云，倒是不受这次迁移的影响。这一切的原因都是因为选择了uni的框架，鉴于所谓的省时省力使用了uni的管理后台和推送服务，这包装好的一切虽然前期省了时间，如果没什么变数长期运维整体成本感觉也还可以。只是一点有了变数之后，所有的一切不说是推到重来，实际上跟挖了重载也差不多了。
之所以说这件事情，还有一件事情，上周五有个哥哥加qq问findu 是不是收费，能不能下载新版本。
其实，上来就说app闪退就可以了。来回折腾了半天我才直到是闪退，问了下手机版本 iPhone 15 pro, iOS27。自己的手机前几天也升级到了27，但是并没有闪退，虽然我猜测可能是ios版本问题，但是鉴于自己的手机没闪退，又猜测是不是硬件问题。
好在最后哥哥在自己的一通指挥下成功的把app崩溃日志发给了自己：设置 → 隐私与安全性 → 分析与改进 → 分析数据，在里面找到对应 App 的 .ips 文件（命名一般是 App名-日期-时间.ips
看到这一堆文件，心理瞬间没那么慌了，毕竟有了文件，就知道是崩在哪里了。
系统断言： You cannot set a delegate on the default file manager. 符号化后的调用链： -[NSFileManager setDelegate:] -[PDRCoreApp copyOverlayFile] ← DCloud 引擎 -[PDRCoreApp load] +[PDRCore initEngineWihtOptions:...] -[AppDelegate didFinishLaunching...] 也就是说：iOS 27 禁止给 NSFileManager.defaultManager 设 delegate，而 DCloud 离线 SDK 启动复制 www 资源时还在这么做，所以一进启动页就 EXC_BREAKPOINT 秒退。崩溃二进制 UUID 与 10/8 的 4.0.5 Archive 一致。
这个问题，其实在上次兼容适配iphone duo的时候修复过一次了，不过那次是在家里的mac mini上操作的，而mbp的xcode 不知道什么时候也升级到27了，这就导致打出来的包使用了ios 27的sdk，就直接引入了这个bug。
当然，更诡异的是自己从26升级到27的系统上，之前安装的findu并没有闪退，卸载重装就是就闪退了。
这个东西的原因后来也想明白了（后知后觉，今天才想明白），在ios26上已经完成文件复制了，所以系统升级之后，并不会再次触发文件复制。而新装的app在启动的时候会复制文件就bug了。
所以，如果uniapp 离线打包ios27闪退，那就直接修改离线工程的代码吧xcode_project/Findu/Findu/NSFileManager+Findu.m（+load swizzle）：
#import <Foundation/Foundation.h>
#import <objc/runtime.h>
#import <string.h>
// iOS 27 SDK 起，Foundation 会在 -[NSFileManager setDelegate:] 作用于
// defaultManager 且 delegate 非空时主动陷阱（EXC_BREAKPOINT）。
// DCloud PDRCoreApp copyOverlayFile 启动时仍靠这个委托把 www 合并进沙盒，
// 会在启动页秒退。兄弟项目 dayima 已验证本补丁。
//
// 非共享的 NSFileManager 不会陷阱。先在临时实例上走系统实现，
// 再把 _delegate / _weakDelegateValue 挪到 defaultManager 上。
// _delegate 是 assign。_weakDelegateValue 必须强持有：
// object_setIvar 对未知所有权按 unsafe_unretained 写入，临时实例释放后
// NSWeakObjectValue 被回收，后续文件操作会打到野指针。
static IMP findu_originalSetDelegate;
static void findu_nsfilemanager_setDelegate(id self, SEL _cmd, id delegate) {
if (delegate != nil && self == [NSFileManager defaultManager]) {
NSFileManager *donor = [[NSFileManager alloc] init];
((void (*)(id, SEL, id))findu_originalSetDelegate)(donor, _cmd, delegate);
Ivar delegateIvar = class_getInstanceVariable([NSFileManager class], "_delegate");
Ivar weakIvar = class_getInstanceVariable([NSFileManager class], "_weakDelegateValue");
if (delegateIvar != NULL) {
void *rawDelegate = (__bridge void *)delegate;
void *slot = (char *)(__bridge void *)self + ivar_getOffset(delegateIvar);
memcpy(slot, &rawDelegate, sizeof(rawDelegate));
}
if (weakIvar != NULL) {
object_setIvarWithStrongDefault(self, weakIvar, object_getIvar(donor, weakIvar));
}
return;
}
((void (*)(id, SEL, id))findu_originalSetDelegate)(self, _cmd, delegate);
}
@interface NSFileManager (Findu)
@end
@implementation NSFileManager (Findu)
+ (void)load {
Method method = class_getInstanceMethod(self, @selector(setDelegate:));
if (method == NULL) {
return;
}
findu_originalSetDelegate = method_getImplementation(method);
method_setImplementation(method, (IMP)findu_nsfilemanager_setDelegate);
}
@end
以前做的东西，并没有很多与硬件交互的内容，所以uni 『从从容容游刃有余』，现在随着对接apple watch 以及carplay，uni变得越来越『匆匆忙忙连滚带爬』了。
毕竟，启动闪退这种bug对于任何app来说都是无法忍受的。好在这次苹果的审核还是非常不错的，提交之后第二天就通过了。
这一桩桩一件件，怎么想都是事儿。只是，真的要推倒重来，真的太需要勇气了。毕竟，已经修复了无数的问题。
所以，做产品，如果要长期做，宜长远考虑。
2026-10-19 13:10:24
更简单更智能的大姨妈记录app：https://guimiquan.cn
版本号：5.3.20 更新内容： 1.会员权益大调整，只需要开通VIP就可以体验语音识别，快捷指令，再也不用一条一条记录啦。一条命令就可以记录数条信息，补充记录几天的数据也不用来回切换日期了。 2.修复了一些已知bug 3.iOS版本支持Apple Watch
APP以及小程序二维码，扫描即可安装体验：
这次更新的时间间隔比较短，但是整体的ai快捷指令处理能力得到了质的飞跃，采用新的mcp服务模式，不再通过指令匹配。同时，增加了apple watch 支持，在设置app背景图片之后，手表的背景会同步设置。
视频：
当然，如果大家感兴趣可以关注我的抖音，每天分享健康知识。
跟着姐姐一起涨知识哦，各种各样的小知识。
2026-10-19 10:06:33
简单更新，支持广告屏蔽（安卓，ios暂未发版）。不得不说，手机上各种广告入侵，很多页面都直接没法看了。
实际效果：
以下内容，写与 2026 年 10 月 14 日 ：
博客聚合这个东西，不说已经被玩烂了，反正是也差不多人手一个了。层出不穷的聚合平台，几乎每个玩博客的都整合了一个，哪怕没有聚合平台，也会有个友圈，邻里之类的rss文章聚合页面。
日薄西山的时候，做这么个东西，似乎也没什么太大了意义，少数人的东西，也难成气候。现在还在写博客的多多少少都有些执拗吧。从几个月之前开始借鉴别人的想法加上自己的创意搞出来这个东西。如果说惊艳，那自然是没有，如果说用途，那也有一些。现在也基本是自用居多，仅此而已。为了上架苹果应用商店，期间也进行了无数次交涉，一次次整改，在整改的过程中添加新的功能。终于昨天这个东西审核通过了。
在迭代过程中，增加了数项功能，主要网站状态相关：离线检测、合规检测、抓取状态检测等等，也会伴随着app推送消息。功能简介：
你来啦！是一个博客站长聚合平台。每个站点根据其 IP 地址映射到虚拟坐标空间， 同时通过坐标转换服务获取真实地理坐标，在天地图（现实坐标）上展示。 ✦ 虚拟 虚拟坐标 · 基于 IP 地址的 Hilbert 曲线映射，探索独特的 IP 宇宙现实 天地图 · 真实地理坐标展示，看看博主们都在哪里
IPv4 / IPv6 双栈 同时支持 v4 和 v6 地址的地图点位展示
友链 在站点列表、地图与详情页点击「链接」添加友链，关系会展示在地图关系网与用户主页。 登录后可在 控制台 管理友链，并通过 Halo / WordPress / Typecho 插件与博客双向同步。
最新动态 全站收录站点的 RSS 聚合信息流，在 最新动态 按日历日切换浏览，支持关键词搜索；登录用户可收藏感兴趣的文章。
朋友圈 已链接友链站点的 RSS 时间线，在 朋友圈 按日浏览已关注（友链）站点的 RSS 更新，支持搜索与收藏。
RSS 订阅 与友链「链接」独立：订阅只用于个人 RSS 阅读，不影响关系网展示。站点列表、地图与详情页均可一键订阅； 控制台支持分组管理与 OPML 导入，在 我的订阅 按日聚合浏览已订阅站点的最新文章。
首页合规扫描 平台会定期检查仍在运营、且填写了网址的站点首页，识别违法违规、恶意跳转和导流内容。 被标记的站点会出现在登录后的预警列表里：站点名称完整显示，域名和网址已脱敏，不能直接打开。 确认违规的站点会被下线；若你的友链里包含这类站点，且开启了友链合规通知，我们会用推送和邮件提醒你及时清理。 这项检查与文章动态的内容过滤相互独立。更完整的说明见常见问题。
下载地址：
苹果：https://apps.apple.com/cn/app/%E4%BD%A0%E6%9D%A5%E5%95%A6/id6790620612
安卓：https://app.zhongxiaojie.cn/app/nilaila/android/
已知问题：当前版本推送模块打包存在问题，正在发布新版，请耐心等待。
推送已经修复，请及时更新新版本。
邀请码：
邀请码 状态 使用者 备注 创建时间 操作 INV-MSPW-C3PZ-XY6A 已使用 ios 2026/10/14 10:03:25 INV-C2K7-F5VR-G5C2 已使用 - ios 2026/10/14 10:03:25 编辑备注删除 INV-H26S-PVBW-BW00 已使用 - ios 2026/10/14 10:03:25 编辑备注删除 INV-EFT1-RDZ5-970T 已使用 - ios 2026/10/14 10:03:25 编辑备注删除 INV-I370-HDMG-GC58 已使用 ios 2026/10/14 10:03:25 INV-XXZK-G8G9-KFV7 已使用 ios 2026/10/14 10:03:25 INV-D9AR-G07C-RDE8 已使用 - ios 2026/10/14 10:03:25 编辑备注删除 INV-YYXI-30UW-0T14 已使用 - ios 2026/10/14 10:03:25 编辑备注删除 INV-OM0Z-JCXW-QWS4 已使用 ios 2026/10/14 10:03:25 INV-4E8S-S6PX-Z7WI 已使用 - ios 2026/10/14 10:03:25 编辑备注删除
补一组邀请码：
邀请码 状态 使用者 备注 创建时间 操作 INV-X3UH-JMQR-5GCN 已使用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-W041-OJVL-HSMI 可用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-VNOU-V6EZ-JFP5 可用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-JVK4-Y5S8-OGEF 可用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-X9NM-Q785-20BS 可用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-BBKL-3GFM-Y4HI 可用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-ACDC-MHUR-F21N 可用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-AGXA-47D0-QPJS 已使用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-NKW4-POEB-59JF 可用 - 补一组 2026/10/15 23:00:29 编辑备注删除 INV-QL2H-GHER-S86V 可用 - 补一组 2026/10/15 23:00:29 编辑备注删除
2026-10-14 09:39:26
随着开发的服务和应用越来越多，当初为了省事直接通过后端提供服务的做法，从短期看来的确是省了再次部署的麻烦。但是，这种做法也挖了一些深坑，并且，这些坑不见得什么时候就成了拖垮系统的罪魁祸首。
当初为了省事，很多服务直接通过端口映射之后就作为后端服务发布了。
当然，并不是直接暴露后端真实服务器的地址，前面还套了一层eo。想着最前面是eo，默认请求都会经过eo转发，本身图片等相关资源都有cdn缓存也不会打到服务器上，只有cdn边缘服务器第一次请求的时候会访问真正的后台文件，这样原来，直接通过后端服务提供静态资源访问也是足够的，并且跑了这么长时间也没什么问题。但是，事实并非总是这么可靠。
昨天 你来啦 发版之后，想着填写一下appstore的下载地址，结果登录后台直接提示502了。
登录服务器看了一下，后台服务进程被大量下载直接拖死了：
22.79.117.157:55212 - - [13/Oct/2026:16:26:03] "GET /media/packages/2026/10/__UNI__8813F79_1007202252.apk" 200 79556639 113.219.202.124:5113 - - [13/Oct/2026:16:26:03] "GET /media/packages/2026/10/__UNI__8813F79_1007202252.apk" 200 79556639 113.219.202.2:12879 - - [13/Oct/2026:16:26:04] "GET /media/packages/2026/10/__UNI__8813F79_1007202252.apk" 200 79556639 113.219.202.3:46581 - - [13/Oct/2026:16:26:04] "GET /media/packages/2026/10/__UNI__8813F79_1007202252.apk" 200 79556639 222.79.116.209:27848 - - [13/Oct/2026:16:26:04] "GET /media/packages/2026/10/__UNI__8813F79_1007202252.apk" 200 79556639 222.79.116.184:59270 - - [13/Oct/2026:16:26:04] "GET /media/packages/2026/10/__UNI__8813F79_1007202252.apk" 200 79556639 2026-10-13 16:26:25,486 WARNING Application instance <Task pending name='Task-6311' coro=<ASGIHandler.__call__() running at /home/obaby/soft/baby-claw/upgrade-server/venv/lib/python3.10/site-package s/django/core/handlers/asgi.py:170> wait_for=<Future finished result=None>> for connection <WebRequest at 0x7f5ee03d73d0 method=GET uri=/media/packages/2026/10/__UNI__8813F79_1007202252.apk clientpro to=HTTP/1.1> took too long to shut down and was killed. 2026-10-13 16:26:25,542 WARNING Application instance <Task pending name='Task-6348' coro=<ASGIHandler.__call__() running at /home/obaby/soft/baby-claw/upgrade-server/venv/lib/python3.10/site-package s/django/core/handlers/asgi.py:170> wait_for=<Future finished result=None>> for connection <WebRequest at 0x7f5ee0255390 method=GET uri=/media/packages/2026/10/__UNI__8813F79_1007202252.apk clientpro to=HTTP/1.1> took too long to shut down and was killed. 2026-10-13 16:26:25,543 WARNING Application instance <Task pending name='Task-6350' coro=<ASGIHandler.__call__() running at /home/obaby/soft/baby-claw/upgrade-server/venv/lib/python3.10/site-package s/django/core/handlers/asgi.py:170> wait_for=<Future finished result=None>> for connection <WebRequest at 0x7f5ee03a3c10 method=GET uri=/media/packages/2026/10/__UNI__8813F79_1007202252.apk clientpro to=HTTP/1.1> took too long to shut down and was killed. 2026-10-13 16:26:25,543 WARNING Application instance <Task pending name='Task-6351' coro=<ASGIHandler.__call__() running at /home/obaby/soft/baby-claw/upgrade-server/venv/lib/python3.10/site-package s/django/core/handlers/asgi.py:170> wait_for=<Future finished result=None>> for connection <WebRequest at 0x7f5ee01ebfd0 method=GET uri=/media/packages/2026/10/__UNI__8813F79_1007202252.apk clientpro to=HTTP/1.1> took too long to shut down and was killed. 2026-10-13 16:26:25,543 WARNING Application instance <Task pending name='Task-6357' coro=<ASGIHandler.__call__() running at /home/obaby/soft/baby-claw/upgrade-server/venv/lib/python3.10/site-package s/django/core/handlers/asgi.py:170> wait_for=<Future pending cb=[Task.task_wakeup()]>> for connection <WebRequest at 0x7f5ee03d7760 method=GET uri=/media/packages/2026/10/__UNI__8813F79_1007202252.ap k clientproto=HTTP/1.1> took too long to shut down and was killed. 2026-10-13 16:26:25,548 WARNING Application instance <Task pending name='Task-6368' coro=<ASGIHandler.__call__() running at /home/obaby/soft/baby-claw/upgrade-server/venv/lib/python3.10/site-package s/django/core/handlers/asgi.py:170> wait_for=<Future finished result=None>> for connection <WebRequest at 0x7f5ee01892d0 method=GET uri=/media/packages/2026/10/__UNI__8813F79_1007202252.apk clientpro to=HTTP/1.1> took too long to shut down and was killed. 2026-10-13 16:26:25,548 WARNING Application instance <Task pending name='Task-6373' coro=<ASGIHandler.__call__() running at /home/obaby/soft/baby-claw/upgrade-server/venv/lib/python3.10/site-package s/django/core/handlers/asgi.py:170> wait_for=<Future pending cb=[shield.<locals>._outer_done_callback() at /usr/lib/python3.10/asyncio/tasks.py:864, Task.task_wakeup()]>> for connection <WebRequest a t 0x7f5ee0058310 method=GET uri=/media/packages/2026/10/__UNI__8813F79_1007202252.apk clientproto=HTTP/1.1> took too long to shut down and
这一堆请求__UNI__8813F79_1007202252.apk的访问，几乎是在同一秒内发出的，并且这些ip也不是eo的cdn边缘服务器ip，那么就只有一种可能，就是源服务器的地址暴露了，被别有用心的的人用来洗白流量了。这种大文件请求，也是pcdn常用的技俩，正好服务器还有大资源文件，带宽又够，的确是个不错的软柿子。
鉴于在这种情况下，要解决这个问题也简单，那就是直接屏蔽掉除了eo节点之外的所有的直接流量，此时只需要找到eo的服务器列表，添加到安全组或者防护策略或者nginx的配置文件中即可，然鹅，eo免费版本并不具备此功能：
那么，应该怎么办？就只能坐以待毙吗？当然，可以通过解析加速域名的dns解析获取所有的边缘测地址：
只是这种做法难免有些不入流。
这就黔驴技穷了？那肯定不可能，想姐姐我是何种人物，没了张屠夫还非得吃带毛的的
？
基于边缘测的请求改写，给所有的请求添加一个自定义头，在源服务器检测就可以解决这个问题了。
边缘测：
服务器配置：
如果是openresty，直接写到nginx.conf 的http部分即可：
# 只放行 CDN 回源。直连源站（IP 或绕过 CDN）没有该头，返回 403，不读盘、不进 Daphne。
# CDN 需在回源请求上添加：baby-fuck-playboys: baby-fuck-all-invalid-requests
# rewrite 的 if 只能写在 server/location，放进 http 段会 nginx -t 失败，也盖不住各 vhost。
# access 阶段对所有 server / location 生效，先于静态文件、FastCGI、反代。
access_by_lua_block {
if ngx.var.http_baby_fuck_playboys ~= "baby-fuck-all-invalid-requests" then
return ngx.exit(403)
end
}
如果是nginx 需要在每个server下面单独进行配置，当然也可以写成一个统一的配置文件，在需要启用检测的地方直接include即可。
# 只放行 CDN 回源。直连源站（IP 或绕过 CDN）没有该头，返回 403，不读盘、不进 Daphne。
# CDN 需在回源请求上添加：baby-fuck-playboys: baby-fuck-all-invalid-requests
if ($http_baby_fuck_playboys != "baby-fuck-all-invalid-requests") {
return 403;
}
配置好之后重启openresty 或者nginx，此时没有合法请求头的访问就直接403了：
小技巧：如何修改postman的host，正常情况这个东西是不让修改的，显示calculated when request is send。那么，取消掉原来的默认host，在下面新建一个，填写自己想要使用的host就可以了。
等eo边缘测部署生效了，网站可以就可以正常访问了。
当然，前提是别改漏了。域名实在是太多了，有两个就给忘了：
2026-10-12 10:58:22
上周的时候看到有人提到关于评论区链接地址的安全性问题，这个所谓的安全性指的是访客的域名是不是还是一个健康的站点。鉴于博客圈人来人往，这个事情就变得非常不可控。毕竟，一旦博主放弃了域名或者卖了域名，那些链接就变成了一个地雷，不知道什么时候会炸掉。
除了评论，还有另外一个也可能会出问题的地方，就是友链。相对来说，友链比较固定，哪怕出了问题也比较容易全部处理掉。为了解决这两个问题，我在nilai.la 启动了个新的服务，专门用来检测现在已经添加的所有链接的健康成都，在检测到异常问题之后会给我发邮件以及app推送消息。如果我确认网站有问题，会同时给所有关注这些站点以及添加了这个站点友链的用户邮箱发送邮件。当然，这个检测不会遍历所有的页面，主要是检测首页，词库数量可能也会影响检测质量，不过聊胜于无，总比什么都不知道会更好。
除此之外，给优化了所有评论区的链接点击，url也不再显示明文，点击之后会弹窗提示之后进行跳转：
当然对于这种前后端分离的页面，如果不渲染页面本身也看不到url信息。
上周的时候，看到另外一条消息，那就是苹果要求app在27年4月之前强制适配iPhone Duo，在这之后提交的更新必须要包含Duo的截图，否则连提交审核的资格都没有。https://developer.apple.com/cn/iphone-duo/
对于各种比较新的技术和设备，我一向不会迅速跟进（主要是因为穷，买不起新的设备）。包括之前的apple watch、carplay，apple watch 很久之前就有了，但是却不曾针对它做过任何的开发。carplay 后来有了却局限于各种权限申请，直到最近才开始做一些开发，陆续上线。至于其他的设备，那是真的买不起，例如最新的Duo。
不过，既然苹果说了这个东西，还是要尝试下的。平常使用的mbp，磁盘空间实在有限（天天报磁盘空间已满），暂时也没想着去把xcode 升级到27.1，就把家里的那台mac mini 利用起来，安装了27.1版本的xcode。
这台m2的mini 入手之后其实并没有怎么用，之前总是觉得带不动两个4k显示器（后来发现是hdmi线缆问题导致的），一直用的windows。还有另外一个问题，那就是性能的确比自己的windows电脑差的太多。
重新升级各种工具，环境之后，就可以启动duo的模拟器了。在这个8g内存的mini上运行模拟器的确是比较折磨人。系统非常卡，毫无体验可言。如果同时运行多个模拟器：watch，iPhone系统的可用性就变得更差了。
不得不说，当时为了便宜，买了个8g版本还是失算了，如果要做开发之类的用途，最好还是16g起步的版本吧，否则在上面开发就是折磨。
目前的适配效果：
app在这种折叠屏的适配上，主要是重新布局绘制的修改和工作量，目前uniapp 官方的打包暂时还不支持iPhone duo的适配，所以直接从云打包打的自定义基座无法运行在iphone duo上，需要下载离线打包sdk和工程修改编译目标配置来实现打包。Duo 模拟器的架构是arm64 ，而传统模拟器的架构是x86-64，当然之所以无法运行并不单纯是架构的问题，iOS sdk升级之后调整了部分方法废弃了部分方法，导致原生的xcode 离线打包的示例项目及时能跑起来也可能会白屏，要修复这个问题又是一顿折腾。
除此之外，这几天还折腾了一下apple watch的适配，当然，如果我所料不错的话，那就是料对了，uniapp 同样无法支持apple watch的打包。也就是说，如果要开发apple watch应用依然要用原生开发，并且这个东西开发完之后，连ai都建议我直接离线打包，把所有的东西复制进去。不过这件事情，是在我开始折腾Duo适配之前搞的，我并不想去搞所谓的离线打包，毕竟要同步的资源太多了，更何况已经开发了一堆原生插件，如果在弄个原生工程，何不直接xcode 原生项目重构？鉴于我对ios 系统以及架构的了解，最终让ai按照自己的想法来实现了这个apple watch的打包运行，代价就是又写了一堆脚本。当然，如果最后还是要靠原生xcode项目，或许，不该写这一堆脚本。
时过境迁，原来为了节省开发时间，便于代码维护的一些方法或者框架，在功能实现越来越底层，交互要达到原生水平的时候，很多事情就不得不向原生开发转移，这么一来，原来的跨平台优势当然无存，取而代之的是各种插件以及原生组件的维护。之前就因为uni的性能问题，把Portable AI的ios端app直接用swift重写了。现在又因为底层交互以及设备支持，原生实现了healthkit 插件，apple watch app，carplay 插件，为了兼容iPhone duo 修改了uni的离线打包示例代码。这一系列的开发升级维护，让uni的跨平台和单代码优势所剩无几。
当然，如果只是做一个跨平台的app，不涉及底层交互，不涉及原生设备适配，uni还是不错的选择。对uni来说，要适配的东西或者设计的东西依然不少，之前鸿蒙兼容的时候，放弃了vue2。鸿蒙的代码我用vue3重构了，现在再次升级兼容的时候，不知道又会放弃什么，至于uniapp x所谓的接近原生的运行效率，是个不错的尝试，但现在在ai横行，无处不在的情况下，这种跨平台优势和所谓的性能优势，依然不再明显。
为了实现自己的各种目标和要求，代码的数量依然与项目开始的时候不是一个数量级了，太多原生语言开发的内容以及插件的大小限制，让我不得不考虑如果再开发一个新的app的时候是否依然要uni梭哈了。
屎山有的是因为代码写的烂，有的是因为从开始就注定了只能拆东墙补西墙，uni搞不定的上插件，插件依然搞不定，那就只能原神重构。
更何况，屎山这个东西是移不完的，为了实现功能，总是要写代码。
这世界上本没有屎山，写的代码多了，屎山自然也就出现了。
