obaby 𝐢‍𝐧⃝ void

Unicloud 云服务空间迁移不完全指南

obaby — Thu, 29 Oct 2026 07:02:56 +0000

你要稳稳的幸福，那稳稳怎么办？

简单朴素的想法总是觉得，自己花钱了或者找大厂的服务肯定比自己弄要稳定很多。但是事实是这样的吗？不是偶尔不是这样的，而是从来不是这样的。

我们看看google 都关闭了那些服务：

当然这些服务，对于开发者来说其实没那么大的影响。但是，国内的大厂的服务就靠得住吗？也未必，Findu旧版本依赖的阿里云的openim 旺信，最开始说是免费，到时候停止服务，也不过短短几年时间。因为这个原因，也导致自己直接放弃了之前的旧版本的维护。这次要说的是闺蜜圈APP的unicloud的云服务依赖。

上个月服务到期之后，直到续费才发现续费周期最长只能选择几个月，下面一行字写着：因阿里云 EMAS 功能逐步下线，uniCloud阿里云服务空间自2026年11月1日起不再支持新建，并将于2027年9月30日正式停服，续费后的到期时间不得晚于2027年8月31日，建议您尽快迁移，

点进公告之后，提示显示可以加群获取迁移工具，然而加群之后，工具却迟迟没有发布出来：

中旬的时候，看通知说月底发布。后来点开还是说是月底发布，现在依然是月底了。却连工具的影子都没看到，不得不说看来他们是真的不着急。

既然他们不着急，自己也不想再等了，不如完全自己动手吧。动手之前首先要清理清楚自己用到了uni的那些云空间的功能，可能的功能包括：

1.uni-id 账号登录系统（）

2.uni-admin 管理后台（✓）

3.uni-upgrade-center app升级管理工具（✓）

4.uni-push 推送工具（✓）

5.uni-statics 统计（✓）

6.uni-chat ai会话框架（✓）

7.其他的关联服务（）

这么看起来，要迁移的东西不少，那么既然迁移就不得不提到另外一个问题，关于uni的云空间计费问题。虽然数据量不大，但是很多计费规则其实是从不同的维度对同一个东西的反复计数，这就导致一个仅有一万多用户的app 云空间每到月底就频繁提示剩余资源不足：

所以在实际迁移之后，准备放弃以下内容：

2.uni-admin 管理后台（✓）

3.uni-upgrade-center app升级管理工具（✓）

5.uni-statics 统计（✓）

所以，要迁移的东西也就少了很多，数据可以完全丢弃，只需要迁移云函数就可以了。保证推送以及 uni-chat的相关功能可以正常使用即可。不过新建空间的时候要注意，支付宝云不支持 universal-links。如果app已经绑定了通用链接，建议迁移到别的地方去，直接放到app的后台或者官网上。

并且支付宝云，哪怕你上传了文件，实际进行校验的时候仍可能过不了：

上传到自己的官网直接源码格式修改manifest.json文件，改成自己的正确地址就可以了。

剩下的就是常规部署流程：

1.云函数重新上传，直接通过hbuiler关联空间，上传代码即可：

2.数据库同步，目前没有工具，如果需要同步数据，可以通过后台数据库生成初始化数据导出数据，将导出数据复制到hbuider初始化代码的目录下，重新初始化数据库（注意：每次最多选20个表，并且在执行导出的时候，不要再去导出操作，会全部失败！）：

如果上面的数据有问题，最可靠的就是通过数据库页面的导出功能导出jsonl格式的数据，在另外一个数据库直接导入：

3.云空间的资源同步？

抱歉，目前没有任何办法，甚至连批量下载的方法都没有。hbuilder带的云空间管理也只能查看，没有批量下载，这个就等官方吧。

4.迁移之后的域名绑定，需要重新绑定域名的几个地方：云空间的自定义域名、云函数的自定义域名。

如果不能直接修改绑定关系，可以添加一个新的域名，修改后端代码，新服务使用新的域名，旧的保持继续可用就行了。

之所以可以这么做是因为支付宝云支持绑定多个域名，所以后期可以把之前阿里云的域名也绑定过来，这样旧版的服务依旧可以正常运行。

如果不涉及到云空间的图片资源等等之类的到这里就算迁移结束了，至于代码怎么改，可以直接扔给ai。或者让ai跑一遍迁移分析，给出迁移步骤以及需要处理的内容和注意事项：

| 阶段 | 内容 | 状态 |
| --- | --- | --- |
| 0 | 准备与确认 |  已逐项复核（2026-10-24）。时间线/HBuilderX/密钥/云函数/索引均通过；备份含结构（54 集合）+ 全量数据（355,378 条），已核实无用户/订单/push cid |
| 1 | 新空间创建 |  完成 |
| 2 | 数据库迁移 |  表结构完成（3 张已上传，无数据搬运）；2.2 数据迁移 / 2.3 索引 / 2.4 验收均**不适用**（2026-10-24 确认） |
| 3 | 云函数部署 |  完成（`babyUniPush` + `uni-ai-chat` 均真机验证） |
| 4 | 推送切换 |  服务端 + 真机已验证（在线通道 `successed_online` 待复测） |
| 5 | 云存储 |  完成（APK / 图标 / 二维码全部切外部域名） |
| 6 | Universal Links |  全链路就绪（`.well-known` + 根路径均 200，深路径兜底已上线，Apple CDN 已收录）；仅剩重新打包 + 开放平台填 UL |
| 7 | 客户端配置与发版 |  未开始（小程序域名、重新打包；打包前需修 `Dayima-Info.plist` 占位值） |
| 8 | 后端 |  完成（唯一对接点 `uni_push.py` 已切） |
| 9 | 切流与收尾 |  未开始（全端回归、旧空间保留） |

需要特别注意的一点，就是那个uni-upgrade-center这个东西和你绑定的域名没有任何的关系，所以如果app升级服务用的uni的服务，那么只能强制更新，让旧版本升上来才能解决这个问题。

## 阶段 6.5：旧版本 App 升级（uni-upgrade-center 兼容）

> 背景：≤ 5.3.20 的包升级走 **uniCloud 云函数** `uni-upgrade-center`；
> 2026-10-20（`d66f6f49`）起改用 HTTP `app.zhongxiaojie.cn/`。
> 旧空间 2027-09-30 停服后云函数消失，需评估对老用户的影响。
>
> 完整契约、真实返回、复现脚本：`开发文档/upgrade-center-接口存档/README.md`

- [x] **查清旧接口的数据拼接方式** ——  2026-10-26，直接调线上云函数采集
  - 请求：`{action:'checkVersion', appid, appVersion, wgtVersion}`
  - 返回：`code 102` 整包 / `101` wgt / `0` 无更新 / `-101` 无版本 / `-102` 参数错
  - 版本比较：按 `.` 分段转数字逐段比，多余段为 0 视为相等
  - 真实响应已原样存档（`raw/`，含 4 个版本用例 + 网关原始外层结构）
- [x] **采集脚本可复跑** —— `probe_upgrade_center.py`，走 uniCloud 阿里云原生协议
  - 签名 `x-serverless-sign = HMAC-MD5(排序后 k=v 串, clientSecret)`（**不是 SHA256**）
  - 匿名授权 → `serverless.function.runtime.invoke`
- [x] **兼容方案设计完成，但按决定不上线**（2026-10-26）
  - 映射规则已用临时脚本跑通并与旧接口逐用例对齐：5.2.16→102、5.1.89→102、1.0.0→102、5.3.20→0、缺参→-102、错 appid→-101
  - 设计保留在 `upgrade-center-接口存档/README.md` 第四节，代码未提交（后端仓库已 `git reset` 回退）
  - 原因：见下一条限制——上线也没人调用

###  关键限制：旧包到不了这个接口

旧包调用的是**云函数**，SDK 内写死发往 DCloud 域名：

```js
{spaceId:"mp-77ffff8b-45c8-4ea4-9b30-98594e60f775", clientSecret:"…",
 endpoint:"https://api.next.bspapp.com"}   // 无 failoverEndpoint
```

`spaceId` / `clientSecret` 编译进包内，域名不受我们控制，证书合法无法劫持 —— **无法重定向**。

且旧包弹窗前必调 `uniCloud.getTempFileURL([url])`，同样依赖旧空间存活；
即使能收到请求，这一步失败也会让弹窗被跳过。

> **结论：重写接口这件事本身没意义** —— 旧包只能依赖旧空间活到 2027-09-30。
> 这与服务端实现无关，是客户端编译产物决定的事实。

### 因此真正要做的事

- [ ] 停服前（2027-09-30）把「桥接版本」推给老用户
  - 版本号必须 `> 5.3.20`，且已使用 `app.zhongxiaojie.cn` 新升级服务
  - 建议借旧空间仍在，用 `is_mandatory` 强更把 5.2.x 及更老用户拉上来
- [ ] 停服后仍未启动的设备：升级检查静默失败（`console.error`，不崩溃），
      **App 本体可用**（业务接口在 Django），只能从下载页手动更新
- [x] **附带发现**：旧云函数平台判断有 bug
  - `platform = /iPhone|iPad/.test(event.headers)` —— `event.headers` 是对象，正则恒 false
  - 实测三种头部（`OS:ios` / `uni-platform:ios` / iPhone UA）**全部返回 Android 记录 + APK 地址**
  - iOS 那条 App Store 记录（`5.0.20`）永远命中不了
  - 若将来真做兼容接口，要按平台显式区分（iOS 返回 App Store 链接

一个endpoint:”https://api.next.bspapp.com”} 就直接卡死了所有的可能性！

这是唯一一个无解的问题，如果用了uni的升级服务，请尽快强制更新，先拜托升级服务依赖问题，否则一旦原来的空间停了，那些没升级上来的版本就成了野孩子了。当然，这个东西有解吗？严格说来也有解，只要uni官方支持修改云空间的id，允许复用原来空间的id就可以了。

所以看到这里，如果你想长期做一个产品，或者说运营一个产品，那么还是尽量减少第三方服务的依赖，毕竟他们的死活切实影响到了自己的app的功能，如果真的死了，那时候临时去找个替代品又岂是那么容易？

小厂的靠不住，大厂的也不一定靠得住。

免费的靠不住，收费的也不见得靠得住。

自欺欺人 — 一个程序媛的自白

obaby — Wed, 28 Oct 2026 09:18:55 +0000

早在ai大行其道之前，我就开始做闺蜜圈APP，从第一版发布，到现在已经坚持了差不多三年时间。有时候也不禁会想，人生能有多少个三年。这三年的付出又得到了什么？

几年的坚持下来，当然，也不是一直在全身心的运营这个东西，甚至连给的关注都没那么多。多数时候就那么随意的放在那里，没有运维，没有推广，也没有任何的动作，偶尔想起来自己需要什么功能了才会去更新这个东西。这种自生自灭的做法，在产品的生命周期里其实是大忌。国内的应用商店，安卓基本都有没上，只有苹果的应用商店才算正常，之前设置的所谓的vip功能和付费门槛，也不过是拍脑袋的决定，自然也不会有人真的去购买什么所谓的vip服务，也就导致一个残酷的事实，那就是vip上线之后，只有不到20块钱的收入，这点收入甚至连一个月的服务器费用都不够。那么坚持的意义又是什么呢？

把做的几个产品扔给ai，让分析商业可行性，当然，这个ai就是deepseek。给的答案也很直白：

可行但没钱。

这句说得好啊，基本就是把自己的反馈给复述了一遍。

之前自己说，养猪的、养鸭的散户都没挣到钱，让卖饲料的给赚了，种地的不挣钱，让卖化肥、卖农药的给赚了。现在所谓的独立开发者境遇本质上并无不同，虽然有了ai的加持，一切的开发似乎都变得不费吹灰之力，然是，所有的人都在用一句话需求开发应用的时候，这些应用基本也就没有太大的价值了。

当然，更不值钱的还有创意，现在要想炒个点子，看到别人弄了个什么，自己也搞一个，复刻一个，真的容易。但是没有用户也是事实。没有所谓的蓝海，到处都是人山人海，一个点子上站着无数的人。要想建立用户信任更是难上加难，至于seo aso等等的优化，也是漫漫长路，如果要想app快速出圈，最快的办法就是付费推广。

说道付费推广，这件事情我并不专业。或者说很多程序媛都不专业，一个合格的程序媛或者产品经理，做出来的东西可能没问题，但是真的能抓住用户痛点吗？这个答案却是不一定，所谓的痛点真的找的准吗？至于开发大姨妈记录app初期，最直接的出发点就是无广告，简单，易用。这是个很好的出发点，但是这类app也有解决不了的问题，那就是历史数据的迁移，使用频次等等各种问题。不会有人天天去记录大姨妈，也不会有人天天盯着一个大姨妈记录app看。虽然后期加入了百科之类的东西，却并没有直接入口，可能很多人都不知道会有这样的入口。

在我把这件事情当作一件正事来做的时候，发现要推广一个app也没那么简单，期间考虑过文化衫，二维码等等，当然甚至考虑过地铁站的广告，有几个地铁站是支持个人投放广告的。要投放广告就面临另外一个问题，广告素材，以及转换率的问题。投放到地铁站转化率到底能有多少，其实我不也不清楚，更何况是这种红海搏杀的app，美柚、大姨妈等等一系列app，要从他们的口里分到一杯羹，谈何容易，更何况很多人天天骂美柚，但是你让她用你的app，也不见得会用。

至于Findu，之前放弃掉或许不是什么明智的选择，但是也确实没有时间或者精力去重构，直到ai能力大幅提升之后，这一切才变得有可能。不过，要想在这个地方分的一杯羹，也不容易。各种短视频平台，各种广告，说一个不懂技术的人，通过ai做了个小东西，一个月赚了多少，有了多少用户。

当然，不得不说，成功的肯定有，但是死了的只会更多。如果真的抄个创意就能成功，那些人又怎么会发到短视频平台。死了么，靠着热度，彻底混上编制，这也是个运气活。如果说一个人成功是运气，一个产品的成功也是运气。至于什么其他的努力付出，不过是锦上添花，仅此而已。当然，自己的产品不够优秀，这也是个因素。

在自己开始开发之前，其实对象说过，这个东西竞争太激烈，基本没什么出路。我又何尝不知道这个问题，只不过是不死心，总想尝试一下而已。2c的产品，要想获取用户的确难。如果按照推广的做法获客成本大约在20-30左右一个用户，如果要先得到一个有价值的用户那就更贵了。至于亮点什么的，并没有那么容易突出，你能想到的，别人也能想到，哪怕你想不到的，别人也会想到；你想到的，别人想不到的，照着抄就是了，哪有什么技术壁垒。当ai能手搓二进制文件的时候，这一切幻想就该消失了，所以，以后一个产品的功能可能没那么重要了，在同类产品中，口碑反而变得比功能更值得推广。

之前看别人发过，创业之前该考虑的几个问题。这好在自己是不靠这个东西养活自己，不然，真的在电视剧里都撑不到第二集。

为了解决成本问题，目前已经准备彻底剥离dcloud的相关服务，毕竟这一个月24块钱也是钱，果断换到了4块钱的支付宝云。

再切换之后，开了安卓版本的app强制更新，需要将旧版本强制切换到新版的云空间，uni的cdn流量也是瞬间就见底了。

新版本去掉了大量的云函数调用，这次到月底勉强没有超量。uni在这一块的消耗计算，的确是够狠，各种叠加算量。之前还想要要不要升级云空间，现在看来及时剥离云服务空间是对的，去掉无效调用以及请求。靠升级无法从根本上解决云函数调用次数以及流量不够用的问题。并且这给的流量也的确是难以撑起相关的服务。

最恶心的地方在于，uni-admin 关联的uni-upgrade-center是关联到uni官方的云空间域名的，通过空间id进行更新检测。也就是说，你一旦用了他们的更新服务，后续想通过更换域名的方式来替换掉uni的官方服务是无法实现的，只能通过发版来实现。关于最近uni空间的迁移，我会写另外一篇文章，帮助大家躲坑，如果用uni的话。

说了这么多，你以为我要放弃了？并没有，我还是要继续坚持下去。看等哪天这1万+的用户能到10万。

这次头图，我特意选的锦鲤，希望：能给我带来好运，也能给你带来好运。

狂欢

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