程序媛 Archives - obaby 𝐢‍𝐧⃝ void

孩子气

obaby — Mon, 01 Jun 2026 02:38:23 +0000

周五的时候，忽然接到一个项目的验收通知。甲方通知周六下午两点半组织专家进行验收，这个小项目的成员不多，一共才几个人。几个比较熟悉情况的周末刚好有点事情，只能自己让宝子的姥爷带包子去上课，自己准备去奔赴这几百公里之外的验收。

网上刷段视频的时候，接到同事电话，说领导对于创建的代码仓库有意见，说我们在糊弄，后端代码都编译不过去。

听到这消息，不禁让我对于这领导的能力以及吹嘘的所谓的ai无所不能的论调产生了怀疑。既然你说ai无所不能，那连一个简单的编译报错都解决不了？更何况我下午还刚编译发版了，虽然是屎山代码，该修复的bug还是要修复的，毕竟修复一个少一个。

拉了个线上会议，上来就问，你们这个前后端一起的项目就两个文件夹？两个gitignore都没有？

说实话就是，这个破玩意儿本来就不是前后端放到一起搞的，你要放到一起搞，才给你扔到了一起，现在又开始说缺少ai约束文件等等。至于那个ignore文件，根目录以及前后端项目，每个项目都有独自的gitignore文件，也不知道是眼瞎还是神马的。扯了一通，最后说，等周一再说吧。

下线之后，我直接远程公司的电脑，编译通过之后发了个截图扔到了群里。

这种事情倒是也在意料之内，太多的人拿着所谓的一知半解，就觉得自己无所不知无所不晓，开始导出指挥。我依然记得多年前一家公司招来的研发总监，那种表面文章做到极致的做法自己真的是佩服，连邮件都写得高深，最牛逼的莫过于里程碑不写里程碑，非得拽英文，mile stone还拼错了，写了个mail stone，当时我对着发的通知看了半天实在没想明白这邮石是什么高级货？数秒之后才反应过来他想写的是mile stone。

对于这种事情，自己也有清醒的认知，主要是自己的脸皮跟这些人比起来还是太薄了。对于自己做不到的事情，或者实现不了的东西，总是无法心安理得承诺别人，内心的那种孩子气残留至今，注定没做渣女的潜质。

从12306订好翌日的车票，开始在网上瞎溜达，看到了一篇很有意思的文章，叫做星链：《换友链还在发邮件？——独立博客缺的不是工具，是一张网 – 蛋蛋之家|一枚蛋蛋的自留地》。来一张蛋蛋的配图，大概就知道是什么东西了。

以我浅薄的理解力，我觉得就是制造了一个可见的网络，这个网络让关系变得更加直观了。搂了一眼没有wp，随便聊了聊，不过这个东西的确给自己一些灵感，忽然也想做个类似的玩具。之所以说是个玩具，初期规划就是如此。一款产品从开始要落地有太长的路需要走。

翌日，带着笔记本，踏上去临沂的高铁。去趣域找好玩的域名，现在虽然是想法有了，但是名称与域名都没有。既然要做个玩具，那就要做得专业。哪怕这个东西，后来死掉了，也要看起来像那么回事。思来想去，辗转反侧最后注册了一个nilai.la.中文名字也很简单，就叫做：你来啦！

至于展现身形，最开始也想过这种太空样式的，不过这种做法有个问题，我想要在太空定位每个站点的位置，三维定位固然不错，不过当时没想好怎么去实现这个定位（虽然现在有一些想法了）。退而求其次，转为平面地图，这个地图的设计也简单，直接基于网站的ip地址进行映射，映射到一个平面区域内，在映射之后ip地址越相近的会离得越近。当然，除此之外，我还加了一张地图，可以根据服务器的ip地址进行地里位置显示。这就是我现在实现的这个小玩意儿。

虽然是周六，似乎出城的人不多，高铁站空空荡荡：

在到临沂之前，在高铁上完成了虚拟地图的显示：

到站之后，委托方安排了个接站的，开了一辆非常小的小车。一点多，去羊汤馆简单的吃了点东西，去厕所的时候，看到了这么一个标语：

he，大临沂果然还是厉害。

下午的验收汇报，我们的委托方对于验收流程一无所知，甚至连验收材料都没打印。等开始验收之后，我这本来以为去打酱油的，结果成了汇报主力，就尼码离谱。从两点半扯到四点半，口干舌燥，好在最后还是验收通过了。我现在对于吃也没什么兴趣，婉拒了委托方晚饭的邀请，直接买了回城的高铁票，五点的依然是赶不上了，只能买到六点四十多的。

临沂北站里面真的干净，啥东西都没有，百无聊赖只能继续折腾那点破代码。

一天的暴力使用，笔记本的电量等到了高铁上已经只剩下10%了，找了半天没找到插座，无奈拿出充电宝给笔记本充电。手机开热点，手机的电量也耗的差不多了，结果再插上手机之后，笔记本不充电了。

回头才发现，原来充电插座在座椅中间，另外一排的一个姐妹手机正插在插座上充电。仿佛一瞬间抓到了救命稻草。

经过一天的旅程，在路上把整个系统的架子也就搭的差不多了，一些基础的功能也已经具备。

周日，陆陆续续，又开发了一些其他的模块，包括插件等等。当然，目前跟一个成熟产品还差距很远。不过看起来，像是那么回事了。

插件目前有wp和tp，其他的暂未开发，wp测试过了，tp尚未测试：

插件以及接口文档下载：plugins

由于产品尚未完备，目前开放邀请注册，邀请码：

INV-4Q4N-2KQB-6J91 已使用
INV-2JOY-X1NF-PA1Z 已使用
INV-BE9C-7P1W-XYT2 已使用
INV-PP5V-QVSG-WW8Z 已使用
INV-CH5C-LU7B-JVM1 已使用
INV-S970-RIRN-LDUE 已使用
INV-0H12-BQAY-Q5JY 已使用
INV-DREQ-V0C7-F6FL 已使用
INV-XIH4-EM3W-1GSR 已使用 
INV-IN7A-YX10-VY0A 可用
INV-EDKY-M9U3-24GJ 可用
INV-PD8N-1RGT-MUKP 可用 
INV-UY5Q-7ALX-G8P0 可用 
INV-T90M-W48Y-MN1Q 可用 
INV-LRSS-BZGW-KZUM 可用 
INV-9Q6H-ADH7-ZDYG 可用

地址：https://nilai.la

就这样，一个周末的时间就没了，就这么恍恍惚惚的做了这么一个东西。至于有啥用其实也没啥用，今天是个好日子，儿童节，发布这个一个孩子气的小玩意儿也蛮好的。

毕竟，除此之外，我也不知道还能有啥可玩的。

祝大家永远都能保持童真，远离世俗纷扰。

意义

obaby — Wed, 27 May 2026 07:59:12 +0000

意义，这两个字总是太沉重。太多的时候，想做点什么事情，首先要考虑的是：做这件事有意义嘛？而不是，自己想不想或者愿不愿意做这件事事情。

人生，谈论起来总是个沉重的话题。不是所有的人都能生活的那么潇洒，不管做什么，总是有人觉得自己干的事情犹如把*捅进了他的肺管子一样，让他难受无比，总是要评判一番。余华可以靠《活着》活着，然而我没有《活着》，我却依然要好好的活着。

我喜欢在互联网上到处瞎溜达，就跟街溜子一样，不但喜欢瞎溜达，还喜欢到处评论，就跟那种低等动物喜欢到处撒尿标记自己的领地一样。（各~~位博主不要瞎想，我就是纯粹喜欢你们才去溜达的，不是~~）当然，这种行为，我隐约记得也有人评论过，至于怎么说的，评论的是啥，我也忘了，反正也有很多不好的声音。尽管如此，也无所谓，反正你看我不顺眼，我也看你不顺眼，如果还盯着看，就尿你鼻孔里。

AI快速迭代的好处，就是让普通人也能快速开发一些产品，并且很多产品做的还蛮不错的。有时候我瞎溜达半天，看到别人发布的产品，不由得心生敬意。而我开发产品，基本就这两种原因：

1.被制裁了，付费成本太高，用爱发电的情况下真的不值，例如 Akismet 它总是说我是商业站，让我购买授权，于是，我自己训练模型建立了垃圾评论检测系统：https://anti-spam.zhongxiaojie.cn

2.现有的工具或者组件实在是不满足自己膨胀的欲望和需求。为了显示评论归属地，最开始魔改了wp useragent插件，再后来，自己搭建baby press 前后端分离的博客系统之后，插件系统独立出来，成了归属地查询服务：https://ip.zhongxiaojie.cn 。

之前静态化的wp系统，自己某天心血来潮，转成了前后端分离的系统。在大家都在静态化的时候，我返祖了，嗯，就是这么特立独行，跟王小波《特立独行的一只猪》中，那只猪一样，我也会早晨爬起来爬到屋顶上去吹小号。

在自己迭代了数个版本之后，现在的版本就是大家看到的样子https://zhongxiaojie.cn ,虽然最开始定位是个玩具，不过后来发现自己复刻的wp主题在前后端分离的状态下更好改了，一些想法的实现比修改wp主题要简单的太多，执行效率比wp也要更快，当然，我开源了代码：https://gitee.com/obaby/baby-press-public

当然，还有一个不成理由的理由，就是喜欢造轮子。当自己看到别人的轮子滚的飞快的时候，我总是想自己也弄个轮子试试，尽管这个轮子自己可能会最后直接扔掉。例如上面生成多网站截图的工具，至于起源很简单，就是在dalao论坛看到有人发了个小工具：

说的更直白一点就是喜欢抄作业，这作业抄定然是抄了，不过我的想法是，抄个想法就行，至于怎么实现，还是根据自己的喜好。如果说作业抄的不如原作好，这种作业不抄也罢，抄这么个东西也挺丢人的。

最终，就是这个作业还抄的蛮成功的，最起码，我觉得还是能达到自己的预期的：https://shot.zhongxiaojie.cn

有的时候，我也是个犟种，总是想把东西做好，有时候又会觉得做好了有啥用呢。

所以，不要问，姐姐，你做的这些有什么意义呢？

意义？为什么要意义？

如果真的要意义，那就是我纯粹是闲的蛋疼！

如果真的要追求意义，那就是我要尽快再减掉6斤，去约拍下一套写真！

如果真的要意义，我的目标是百万存款，而不是简单的达成这100万个跳绳！

所以，要意义干嘛呢？多沮丧啊。

闺蜜圈 [v 5.1.88]

obaby — Mon, 18 May 2026 03:09:19 +0000

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

更新记录：
5.1.88
数字版本号：528
华为版本号：5.2.01 550
Apple 5.1.88 528

1. AI助理添加快捷指令开关，可以自行控制是否开启快捷指令处理
2. 修复了部分已知bug

距离上个版本发布已经过去数个月了，这几个月并不是什么都没干，而是想着不断的把她弄的更完美。想继续扩大上架的范围和区域，期间成功了一些，也失败了一些。

成功的几个（三星、oppo[更新]）来之不易，失败的几个更是各种不同的原因，应用商店本身的、各种所谓的政策的。至于如何解读这个东西，这么久了其实自己依然解读不了，只能收到什么整改通知就去做什么类型的整改。

至于整改有没有效果，那就是另外一个故事了。在某些时候迫不得已上了个阉割版本，作为一个注重用户体验的开发者，这的确不是我想看到的。

UniAdmin Invalid uni-id config file

obaby — Fri, 15 May 2026 07:56:17 +0000

上次更新闺蜜圈还是很久之前的事情，最近也确实没顾上自己的这个曾经倾注了无数心血的app。前段时间，申请了华为的商户号，本来以为能正常的上架内购相关的功能，然而最终卡在了商户密钥创建的地方。折腾来折腾去，最终还是没能跨越这个鸿沟，出师未捷身先死。

最后为了满足应用市场的合规需求，进行了功能阉割，现在华为应用市场的版本是个阉割版，如果需要全功能版本，请从官网https://guimiquan.cn下载。原生鸿蒙版本会在稍后更新，同样大概率也是个阉割版。

今天想登录下uniadmin，做下app更新发布，却发现登录不了了：

搜了下这堆错误，发现没什么有用的东西。最后还是得自己动手，按照字面理解就是缺少配置文件，而这个配置文件是登录必须的。打开本地目录发现这个文件竟然真的咩有了。

git追踪发现，不知道在哪个版本之后，文件忽然被删除了。这就挺神奇的，竟然还会少文件，关键是，unicloud的文件也不见了。这真是见鬼了，好在本地还有备份的uni模块目录。去扒拉一通，找到了这个文件：

要解决这个问题，加单来说就是在config目录下新建uni-id，然后穿件config.json文件。

{
    "requestAuthSecret":"sesrct",
  "passwordSecret": "password-demo",
  "tokenSecret": "tokent-demo",
  "tokenExpiresIn": 7200,
  "tokenExpiresThreshold": 3600,
  "passwordErrorLimit": 6,
  "bindTokenToDevice": false,
  "passwordErrorRetryTime": 3600,
  "autoSetInviteCode": false,
  "forceInviteCode": false,
  "app": {
    "tokenExpiresIn": 2592000,
        "tokenExpiresThreshold": 864000,
    "oauth": {
      "weixin": {
        "appid": "填写来源微信开放平台https://open.weixin.qq.com/创建的应用的appid",
        "appsecret": "填写来源微信开放平台https://open.weixin.qq.com/创建的应用的appsecret"
      },
      "apple": {
        "bundleId": "苹果开发者后台获取的bundleId"
      }
    }
  },
    "web": { 
        "tokenExpiresIn": 7200,
        "tokenExpiresThreshold": 3600,
        "oauth": {
            "weixin-h5": { 
                "appid": "微信公众号登录所用的appid、appsecret需要在对应的小程序管理控制台获取",
                "appsecret": "微信公众号后台获取的appsecret"
            },
            "weixin-web": { 
                "appid": "微信PC页面扫码登录配置appid",
                "appsecret": "微信PC页面扫码登录配置appsecret"
            }
        }
    },
  "mp-weixin": {
        "tokenExpiresIn": 259200,
        "tokenExpiresThreshold": 86400,
    "oauth": {
      "weixin": {
        "appid": "微信小程序登录所用的appid、appsecret需要在对应的小程序管理控制台获取",
        "appsecret": "微信小程序后台获取的appsecret"
      }
    }
  },
  "mp-alipay": {
        "tokenExpiresIn": 259200,
        "tokenExpiresThreshold": 86400,
    "oauth": {
      "alipay": {
        "appid": "支付宝小程序登录用到的appid、privateKey请参考支付宝小程序的文档进行设置或者获取，https://opendocs.alipay.com/open/291/105971#LDsXr",
        "privateKey": "支付宝小程序登录用到的appid、privateKey请参考支付宝小程序的文档进行设置或者获取，https://opendocs.alipay.com/open/291/105971#LDsXr"
      }
    }
  },
  "service": {
    "sms": {
      "name": "应用名称，对应短信模版的name",
      "codeExpiresIn": 300,
      "smsKey": "短信密钥key，开通短信服务处可以看到",
      "smsSecret": "短信密钥secret，开通短信服务处可以看到",
            "scene": {
                "bind-mobile-by-sms": { 
                    "templateId": "绑定手机号使用的短信验证码模板", 
                    "codeExpiresIn": 240 
                }
            }
    },
    "univerify": {
      "appid": "当前应用的appid，使用云函数URL化，此项必须配置",
      "apiKey": "apiKey 和 apiSecret 在开发者中心获取，开发者中心：https://dev.dcloud.net.cn/uniLogin/index?type=0，文档：https://ask.dcloud.net.cn/article/37965",
      "apiSecret": ""
    }
  }
}

注意，这个东西就是个json不能有注释。然后重新上传config模块即可。

如果passwordSecret 这个东西变了，可能就得直接去数据库改密码了，好在我的文件还在，不用去改密码。

裸奔

obaby — Mon, 11 May 2026 05:25:00 +0000

每次使用AI来写一点东西，总觉得一切内容都在ai的监视下暴露无疑。当然，那些全新创建的项目也无所谓，本来就是它生成的，但是一些旧项目，在开始ai之后，其实就相当于给ai提供了大量的代码样本和示例。

在ai能力越来越丰富，对于程序员的侵略性变的越来越强的同时，其实也引入了一些新的问题，最主要的就是安全性问题。大量ai生成的代码，无人审计也没有人知道会不会引入一些漏洞或者缺陷。另外一个问题就是，程序员与ai的交互变得可追踪，可重放。问题从来不是得到答案就结束了，后续各种交互过程就成了ai迭代训练的样本。

上图是教主的微博内容，发生这种现象其实毫不奇怪，毕竟交互是要提交相关的代码片段或者实现逻辑的。有时候让ai实现功能，在ai无法达到想要的效果的时候，我也会给出具体的步骤提示，甚至包含示例代码。这些稀缺性的交互内容就成了相对来说价值比较高的样本。

也不是所有的交互都会成为训练样本，毕竟用ai生成的内容训练ai会让ai不断降智，这也是为什么我说以后人工产生的内容（不是国内那种复制粘贴的内容）依然具有较高的价值。

同样对于一些敏感内容的交互，也应该有一定的加密或者保密方式，毕竟这些东西一旦到了云端之后，至于那天会出现在什么地方那就不确定了。这还是使用直连的情况。

如果使用各种聚合服务，那自己的数据就变得更加公开了，几乎所有的聚合服务平台都会记录交互内容。这些内容后期会被聚合服务平台进行售卖，这也是他们收入的一部分。至于这些东西卖给谁，那就更无法追踪了。

所以一些比较私密的项目，建议不要使用这种聚合服务，并且适当控制ai工具的权限。

毕竟，你也不想让别人看到你在互联网上裸奔吧。

浅谈前后端分离系统的SEO优化

obaby — Mon, 27 Apr 2026 02:03:03 +0000

开发一个系统，不管是从头开始，还是在已有系统上二次开发，从来都不是一蹴而就的事情。在上线以前总觉得已经做够了足够的测试，但是在上线之后还是会出现各种各样的问题。

有的问题，如果是新系统完全可以避免，正是由于是在已有系统上开发的为了兼容wp才会引入一系列的问题，这类问题主要是wp原生的一些机制兼容问题导致的包括但不限于：

1.wp固定连接的兼容

2.shortcode的解析处理

3.wp资源文件与新系统资源文件的路径兼容处理

4.wp启用插件的功能实现，邮件通知、micro-post、邮件发送、邮件模板等等

5.其他的未知问题

也有一部分是新系统天生的缺陷：seo不友好，搜索引擎爬虫无法获取网页内容，毕竟robot不会执行js，这个是前后端分离系统的必然缺陷。



  
    
    
    
    
    
    
    
    
    
    
    
    
    obaby 𝐢‍𝐧⃝ void - 程序媛 / 独立开发者 / 智商不稳定的女神经

当然有人会比较在意这个东西，不是说这个东西不对。可能是自己没那么在乎吧，之前就曾经收到过数次关于seo友链不显示的问题，上次是搞页面静态化。

其实，在我的博客添加的友链，也并不是全部都不显示，毕竟还有其他的域名，zhongxiaojie.com 以及 oba.by等还是会显示完整的友链信息，这两个域名并没有切换到新的前后端分离的系统。所以，我博客的友链，相当于数个站都给友链做了多次链接，我不知道这个东西对于seo有没有作用，至于是有好处，还是有坏处，我并不清除，我自己并不是那么关注所谓的seo。如果觉得这样反而会出问题的，欢迎反馈，我会及时删除相关链接哈。

当然，这个东西有办法解决吗？答案自然是有，至于解决方法，那就是继续回归服务器渲染。

这解决方案真的是简单粗暴啊，合着这折腾来折腾去，又要弄回服务器渲染，这辛辛苦苦四十年，一夜回到解放前？

采用这种简单粗暴的方法来解决seo问题，显示不是本仙女的作风。既然是针对搜索引擎的，那就直接对搜索引擎做单独的处理就完了。检测ua，如果是收缩引起的ua返回服务器渲染之后的内容，如果是正常浏览（搜索引擎爬虫意外的ua）返回前后端分离的内容。

要实现服务器渲染，基于vue的可以参考nuxt.js(百度百科):

Nuxt.js是由NuxtLabs团队于2016年10月推出的基于Vue.js的开源Web框架，采用MIT License授权。该框架灵感来源于Next.js，Nuxt采用了约定俗成的规范以及一种明确的目录结构，以实现对重复性任务的自动化处理，并使开发人员能够专注于推进新功能的开发。^[2]^[5]^[8]。

Nuxt默认内置服务器端渲染（SSR）功能、支持静态站点生成（SSG）和单页面应用（SPA）三种部署模式，可通过”nuxt generate”命令生成预渲染HTML文件实现静态化部署^[5]^[7]。采用模块化架构提供50多个扩展模块，支持TypeScript类型安全、推送和现代化开发工具链^[4]^[6]。

接下来也就简单了，创建nuxt项目，实现与frontend同样的页面路由和相关的页面文件布局。接口可以直接复用当前的接口，

配置openresty的处理逻辑：

# -----------------------------------------------------------------------------
# Dynamic Rendering（SEO）：爬虫 UA → Nuxt SSR；普通用户 → 现有 SPA
# - Nuxt SSR 服务建议监听 127.0.0.1:3000（可按需调整）
# - ?__ssr=1 可强制走 SSR（方便自测/排障）
# - 仅对“页面路由”生效，不影响 /assets、/vendor、/bp-api、WP 后台等
# -----------------------------------------------------------------------------
set $bp_force_ssr 0;
if ($arg___ssr = "1") {
    set $bp_force_ssr 1;
}

set $bp_is_bot 0;
if ($http_user_agent ~* "(googlebot|bingbot|baiduspider|yandexbot|duckduckbot|slurp|sogou|360spider|bytespider|petalbot|facebookexternalhit|twitterbot|rogerbot|ahrefsbot|semrushbot|mj12bot)") {
    set $bp_is_bot 1;
}

location @nuxt_ssr {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Uri $request_uri;
}

# 418 跳转技巧：在页面路由里 return 418 → error_page 转到 @nuxt_ssr
error_page 418 = @nuxt_ssr;

启动之后就可以查看服务器渲染的页面了：

当然，这个实现方法的缺点就是得完全复刻frontend的相关路由和页面，优点就是不用关注原来的系统实现逻辑，哪怕爬虫seo系统出问题也不会影响现有的系统运行。

产品，还是玩具？ — Baby Press(缝合怪)

obaby — Fri, 24 Apr 2026 06:58:12 +0000

这算是给这个东西写的第二篇正式的文章，本来我的想法很简单，做一个简单的前后端分离的系统来完全替代wp的php渲染机制。

只是，在开发的过程中为了迎合wp的各种现有数据格式、插件、主题、shortcode等等，代码复杂度也在不断的提高。得益于ai的崛起，现在生成代码是真的简单方便，原来数个人的工作，现在一人就可以完成了。尽管哪怕没有ai，我自己也能全部搞定。ai在某些方便还是提高了输出效率，原本很多人不是全栈的，现在也给搞成了全干工程师，哪怕不会，也得硬着头皮上，去验证ai写的各种代码。

我一般不喜欢给ai太具体的描述，但是会给一个准确的描述，实现方法，实现路径，实现目标，所以多数时候ai呈现的代码质量尚可。然而，等到实际上线的时候发现还是一堆问题。

做完准备把wp的前端全部迁移到现在的baby press的前端，尝试部署之后出现了一系列问题，当然很多问题源自于测试不充分。为了解决两个系统的整合问题，需要大量的配置文件和代码。除了openresty的配置文件，前后端也生成了一堆默认的配置模板，当然，这些模板主要是为了提供一些自定义的功能，以及安全性提升加密等等。

这么复杂的系统，现在我觉得更像一个玩具，而不是产品，好的产品应该是简单易用，开箱可用的。

DJANGO_SECRET_KEY=dev-secret-key-change-me
DJANGO_DEBUG=1
DJANGO_ALLOWED_HOSTS=127.0.0.1,localhost
# 浏览器里「页面」的 origin（协议+域名+端口），须与前端访问地址一致；逗号分隔、勿加路径。
# 生产示例（Vue 部署在 i 子域、API 在 api 子域时，必须把 i 子域写进来，否则会 CORS 失败）：
# CORS_ALLOWED_ORIGINS=http://127.0.0.1:5173,http://localhost:5173,http://i.zhongxiaojie.cn,https://i.zhongxiaojie.cn
CORS_ALLOWED_ORIGINS=http://127.0.0.1:5173,http://localhost:5173
# Django CSRF 信任来源（协议+域名+端口，逗号分隔；用于 /admin/login/ 等表单提交）
# 生产示例：CSRF_TRUSTED_ORIGINS=https://api.zhongxiaojie.cn,https://i.zhongxiaojie.cn
CSRF_TRUSTED_ORIGINS=http://127.0.0.1,http://localhost

# Django 缓存（评论 UA/IP 查询结果）；推荐 Redis，例如 redis://127.0.0.1:6379/1
# 留空则使用 LocMem（仅开发、单进程）
# DJANGO_CACHE_REDIS_URL=redis://127.0.0.1:6379/1
#
# WordPress Object Cache Pro（可选）：Django 直写评论后用于定向清理评论缓存。
# 请与 WordPress 端 WP_REDIS_CONFIG 的 host/db/prefix 保持一致。
# 例如 WP_REDIS_CONFIG 里 database=5，则这里应为 redis://127.0.0.1:6379/5
# WP_OBJECT_CACHE_REDIS_URL=redis://127.0.0.1:6379/
# 注意：当前定向清理实现依赖 prefix，建议在 WP_REDIS_CONFIG 中显式配置 'prefix' => 'zhxj'
# WP_OBJECT_CACHE_REDIS_PREFIX=zhxj
# WP_OBJECT_CACHE_BLOG_ID=0

# Baby IP Lookup：本机 lookup-ua 与静态资源公网域名（PNG/SVG 补全）
# UA_LOOKUP_UPSTREAM_BASE_URL=http://127.0.0.1:18765
# UA_LOOKUP_PUBLIC_ASSETS_BASE_URL=https://ip.zhongxiaojie.cn
# UA_LOOKUP_DEFAULT_METHOD=ip2location
# UA_LOOKUP_CACHE_TTL=604800

# WordPress database connection (MySQL/MariaDB)
WP_DB_NAME=wordpress
WP_DB_USER=root
WP_DB_PASSWORD=
WP_DB_HOST=127.0.0.1
WP_DB_PORT=3306

# WordPress table prefix, e.g. wp_ / wp123_
WP_TABLE_PREFIX=wp_

# 是否信任反代/CDN 转发头（CF-Connecting-IP / X-Real-IP / X-Forwarded-For），默认开启。
# - 生产推荐开启，并配置 TRUSTED_PROXY_IP_RANGES，只信任你的网关/CDN 回源 IP 段
# - 若 API 不会被公网直连，且 CDN 回源 IP 经常变：可保持开启并留空 TRUSTED_PROXY_IP_RANGES（有伪造风险）
TRUST_PROXY_HEADERS=1
# 反代终止 TLS（如 Nginx/Edge/CDN）时建议开启，配合 X-Forwarded-Proto 识别 https
SECURE_PROXY_SSL_HEADER_ENABLED=1

# 额外输出“真实 IP access log”（Daphne 的 access log 里显示的是 CDN 节点 IP）
# 打开后会在 stdout 输出形如：[realip] ip=... remote=... status=... GET /api/...
REAL_IP_ACCESS_LOG_ENABLED=0

# 受信任反向代理 / CDN 的 IP 段（CIDR，逗号分隔）。
# 仅当请求来源 REMOTE_ADDR 命中这些 IP 段时，后端才会信任 CF-Connecting-IP / X-Real-IP / X-Forwarded-For。
# - 本机 Nginx 反代：127.0.0.1/32,::1/128
# - 生产：把你的 Nginx/网关内网地址段、或 CDN 回源 IP 段加入这里
TRUSTED_PROXY_IP_RANGES=127.0.0.1/32,::1/128

# API 请求签名（HMAC + ts + nonce）——默认关闭
# 注意：这是“请求验签”，不是“返回加密”。建议仅在 HTTPS 下启用。
# API_SIGNING_ENABLED=1
# API_SIGNING_SECRET=change-me-long-random
# 允许客户端时间漂移（秒），超出即拒绝（防离线重放）
# API_SIGNING_TTL_SECONDS=60
# nonce 去重缓存 TTL（秒），建议 >= API_SIGNING_TTL_SECONDS
# API_SIGNING_NONCE_TTL_SECONDS=300
# 需要签名的路径前缀（逗号分隔）
# API_SIGNING_REQUIRED_PREFIXES=/api/
# 免签路径（逗号分隔，严格 path 匹配），例如健康检查：
# API_SIGNING_EXEMPT_PATHS=/api/health/,/api/ping/

# SMTP / Email backend (Django)
# 不配置则不会真的发出邮件（除非你使用本地控制台邮件后端等）。
# EMAIL_BACKEND=django.core.mail.backends.smtp.EmailBackend
# EMAIL_HOST=smtp.example.com
# EMAIL_PORT=587
# EMAIL_USE_TLS=1
# EMAIL_HOST_USER=your-account@example.com
# EMAIL_HOST_PASSWORD=your-app-password
# DEFAULT_FROM_EMAIL="obaby "
#
# 评论回复邮件通知（前台回复他人评论时）
# COMMENT_REPLY_NOTIFICATION_ENABLED=1
# COMMENT_REPLY_EMAIL_FROM="obaby "
# COMMENT_REPLY_EMAIL_HEADER_IMAGE_URL=https://zhongxiaojie.com/wp-content/uploads/2026/01/uugai.com_1661691241113463.png
# COMMENT_REPLY_EMAIL_HEADER_IMAGE_WIDTH=520
# COMMENT_REPLY_EMAIL_HEADER_IMAGE_HEIGHT=180
# COMMENT_REPLY_EMAIL_HEADER_ALT=obaby 𝐢‍𝐧⃝ void
# COMMENT_REPLY_EMAIL_FOOTER_LINE1=obaby 𝐢‍𝐧⃝ void
# COMMENT_REPLY_EMAIL_FOOTER_LINK_TEXT=oba.by
#
# 与 WordPress CREN 插件退订链接校验一致（取自 wp-config.php）
# WORDPRESS_AUTH_KEY=
# WORDPRESS_AUTH_SALT=
# 与 WordPress 登录 Cookie（wordpress_logged_in_*）校验一致（同样取自 wp-config.php）
# 推荐配置 LOGGED_IN_KEY / LOGGED_IN_SALT；留空时后端会回退到 AUTH_KEY / AUTH_SALT
# WORDPRESS_LOGGED_IN_KEY=
# WORDPRESS_LOGGED_IN_SALT=

# 服务器状态小组件：统计磁盘路径（Linux "/"；Windows "C:\\")
# SERVER_PROBE_DISK_PATH=/

# 
  Ada Lovelace 



 


  评论： ×0




  同时拥有捷豹跟奔驰（三叉星辉照亮我的路） 




  评论： ×2




  真麻了，一个发版发了好几个月！艹！ 




  评论： ×0




  一切都是表象 




  评论： ×0




  二次元踢踏舞 

https://zhongxiaojie.cn/dance/R%EF%BC%81P%EF%BC%81G%EF%BC%81%E4%BA%8C%E6%AC%A1%E5%85%83%E8%B8%A2%E8%B8%8F%E8%88%9E.mp4
 


  评论： ×0




1
2
3
next » 列表头像：Gravatar 兼容镜像根（路径同 /avatar/{md5}?s=&d=），默认 gg.lang.bi
# GRAVATAR_AVATAR_BASE_URL=https://gg.lang.bi

# 侧边栏「近期文章」：正文无图时的缩略图回退地址
# SIDEBAR_RECENT_POST_FALLBACK_IMAGE_URL=https://zhongxiaojie.cn/wp-content/uploads/2026/01/...

# 评论反垃圾分类（可选；不配置则不调服务、新评论直接通过）
# BABY_ANTI_SPAM_CLASSIFY_URL=http://192.168.1.8:8765/v1/classify
# BABY_ANTI_SPAM_SECRET=change-me-long-random
# BABY_ANTI_SPAM_TIMEOUT=3

# 同一邮箱+IP 对同一篇文章连续提交的最短间隔（秒，0 关闭，最大 120）；依赖 Django cache
# COMMENT_SUBMIT_COOLDOWN_SECONDS=0

# 前台文章评论列表分页（GET /api/wp/posts/:id/comments/）：按一级评论（线程）分页，每页含该层全部回复；不传 page 时默认最后一页（最新线程）
# WP_COMMENTS_PER_PAGE=50
# 客户端 ?per_page= 的上限（不超过 500）
# WP_COMMENTS_MAX_PER_PAGE=200
# 顶层线程展示：desc=递减（最新在上，默认）；asc=递增（最新在下）
# WP_COMMENTS_ORDER=desc

# Nginx FastCGI 缓存：评论审核通过（comment_approved=1）后清理文章页、首页（可选分类页）
# 与 WordPress 插件「Nginx FastCGI Cache Purge on Comment」类似：HTTP GET {站点}/purge{路径}
# NGINX_CACHE_PURGE_ENABLED=1
# NGINX_PURGE_PUBLIC_BASE_URL=https://你的域名
# NGINX_PURGE_TIMEOUT=2
# NGINX_PURGE_SSL_VERIFY=1
# NGINX_PURGE_CATEGORIES=1
# NGINX_CACHE_FILES_PATH=/var/cache/nginx/allinone

# Kama WP Smile：评论表情包资源（给前端下发，避免硬编码域名）
# 若留空，前端会回退使用自身默认/环境变量配置。
# SMILE_PACK_BASE_URL=https://zhongxiaojie.cn/wp-content/plugins/kama-wp-smile-packs/qip_dark_all/
# SMILE_PACK_EXT=gif
# SMILE_PACK_TOKENS=smile,sad,laugh,rofl,blum,kiss,yes,no,good,bad,unknw,sorry,pardon,wacko,acute,boast,boredom,dash,search,crazy,yess,cool,air_kiss,angel,bb,beach,aggressive,blush,bomb,bravo,buba,bye,cry,curtsey,dance,dash2,declare,diablo,don-t_mention,drinks,focus,fool,friends,gamer,give_rose,heart,help,hi,laugh1,mail,mda,mosking,music,negative,ok,popcorm,punish,rtfm,sarcastic,secret,shock,shout,thank_you,vava,victory,beee,big_boss,wink,yu,cray2,dash3,girl_pinkglassesf,girl_prepare_fish,locomotive,lazy2,agree,feminist,fuk,fuck,jester,hunter,moil,offtopic,paladin,shablon_01,spam,vinsent,warning,yahoo,superman,girl_witch,fans,beta,butcher,elf,first_move,gamer2,girl_cray2,girl_cray,girl_blum,girl_dance,girl_crazy,girl_haha,heat,hysteric,nhl_crach,nhl_fight,pig_ball,aikido,angry2,banned,alcoholic,bb2,flood,gamer3,girl_devil,flirt,girl_cray3,girl_drink,girl_hide,girl_hospital,girl_impossible,girl_in_love,girl_mad,girl_sad,girl_sigh,girl_smile,girl_to_take_umbrage,girl_wacko,lazy1,nono,man_in_love,party,scenic,queen,paint,crazy_pilot,dwarf,hang1,haha,grin,good3

好处呢，就是所有的系统配置基本都在这个配置文件中控制即可，无需去各种地方设置了，修改之后重启服务即可。

之所以说是玩具，其实我在wp之外添加了另外一个简单的管理后台，这也是为什么选了django 而没有直接用fastapi。

这个东西最初的目的也不是为了替换wp，所以很多功能也没必要再实现一遍了。基础的操作还是在wp的后台完成。

当然，做完折腾到零点多，补全了一些功能之后，最终还是上线了，这就是目前看到的页面效果，lighthouse测试：

ipv4测试：

ipv6测试：

对于wp的主题，也修改了下页面宽度，与现在的vue的页面宽度基本一致了：

http://zhongxiaojie.com

代码地址：

https://gitee.com/obaby/baby-press-public

偷梁换柱 — 解决『出境易暂不支持此应用。』

obaby — Fri, 17 Apr 2026 07:30:53 +0000

前几天去买手机的时候，销售小哥说，如果你不喜欢这个纯血鸿蒙，或者感觉无法满足需求可以回来去二楼，找技术把系统进行降级。

当时我在想：对于我这种买手机不怎么玩游戏或者需求没那么多的人来说，应该能解决我的绝大多数需求，毕竟系统上还有出境易、卓易通。

然而事情总有例外，自己常用的浏览器vivaldi发现竟然无法安装，这就让人非常的抑郁了。

下载apk安装的时候提示：出境易暂不支持此应用。

哎，咱们可不兴这么搞啊，这就离谱啦。我已我不稳定的智商来猜测这个东西肯定是有个神马白名单或者黑名单机制，至于黑白名单，到时也没那么关键，大不了就改个包名嘛。然而安装 apktool m的时候同样的提示也出现了，这个东西大概率就是黑名单了。

算鸟，算鸟，直接用模拟器改吧：

点击快速编辑：

原来的包名：com.vivaldi.brower,咱们假装是uc咋样呢：

反正我也不用uc浏览器，嘎嘎。

修改之后，发送到手机进行安装，一切顺利，嘻嘻：

鸿蒙next：我要验牌！牌没有问题！

尝试同步功能：

完美！

到这里就结束啦，对于同步问题，有的宝子说非得搭梯子，也不一定。可以直接修改hosts，可以在路由器配置或者dns配置，或者神马别的地方配置：

vivaldi.com. 172.66.165.60
bifrost.vivaldi.com. 31.209.137.10
cdn.jsdelivr.net. 151.101.89.229

Baby Press — 前后端分离的WP系统

obaby — Tue, 14 Apr 2026 01:53:19 +0000

WP的系统怎么说呢，有时候真的感觉一言难尽，庞杂的功能，丰富的插件、主题。几乎能满足所有人的需求，当然，也能满足我的需求。

之所以要做这么个东西，最主要的是前几天在杜老师的聊天室收到一条消息：

跟随这条消息我也去了解了一下这个东西，按照官方的说法，其实是这么个东西：

Cloudflare 将这款项目命名为 EmDash，将其定位为 WordPress 的精神继承者，这并不是对 WordPress 简单的复刻，而是用现代化技术栈，重新实现一套面向未来的 CMS，并且重点解决了 WordPress 24 年发展中积累的的架构臃肿、安全隐患与性能瓶颈问题。

说是高性能的wp，但是实际上跟wp没有任何的关系，除了所谓的精神继承。刚开始我还以为是基于wp的优化，现在看来其实是完全做了另外一套系统，这精神继承，可以说是非常抽象了。

再加上『爱看』在我没有~~丢失以前的网站数据~~的时候，就一直建议可以自己写个系统。重新搭建之后，他又提过几次：

既然 cf可以这么干，那么自己当然也可以这么干。只是，这次自己既不想重写，又不想使用php，于是，我换了最熟悉的django+vue3来实现这个新的系统，至于数据库当然还是用wp原来的。既然设计好这一切，那么声息的就是让ai开始动工了。

当然在开发过程中，不可避免的要面临一些问题，例如wp的shortcode，主题插件的一些功能：相册、代码高亮等等。不过这些东西都可以重新通过python进行处理和渲染。还有一些php的原生小组件渲染就有些困难了，这些只能通过其他方法进行实现。例如归属地、ua，访客信息等等。暂时尚未完成，为了处理ip归属地查询，目前将插件的归属地查询已经独立成了python服务，开源地址：https://cnb.cool/oba.by/baby-ip-location

测试地址：https://ip.zhongxiaojie.cn

当前测试页面效果：

访问地址：

https://i.zhongxiaojie.cn

代码暂未开源，还在继续完善。

Baby Anti-Spam 自建反垃圾评论系统

obaby — Mon, 06 Apr 2026 10:05:11 +0000

很久之前，就经常收到akismet的授权提醒，对应一个错误码10010。

刚开始还以为是多域名访问导致的授权校验出问题了。后来换了n个key，同时添加了插件hook掉所有的垃圾评论检测逻辑，让全部走统一的域名，结果前几天又收到这个提醒了。

插件代码：

这次授权的密钥撑得时间稍微长了点，但是最终还是收到了这个提醒，意思是需要订购商业版授权。我这个人站点为了发垃圾评论订购一个商业版授权，确实有些难以接受。

于是，我决定自建反垃圾评论系统，基于scikit-learn实现了现在的这套垃圾评论检测系统，训练数据一部分来源于github的开源数据，另外一个就是我自己博客的评论数据。为了保证样本正例和负例数量差别不至于过大，经过各种方式进行了多轮数据清洗。

如果想要评论识别更加准确，可以提供自己的博客评论数据，如果能提供垃圾评论更好。现在欠缺的主要是垃圾评论数据，正常的评论数据我已经提供几千条数据。

效果测试：

测试地址：https://anti-spam.zhongxiaojie.cn/test/spam

简介：

面向 中英混合 评论的 WordPress 垃圾识别方案：PHP 插件在评论入库前调用 本机 Python 服务，由小型多语种向量模型 + 分类器（或演示用规则）给出垃圾概率。

适合评论量不大、单机部署（例如 4 核 / 8GB RAM 的 Ubuntu），服务与 WordPress 同机时使用 127.0.0.1 即可。

目录结构：

baby_anti_spam/
├── README.md
├── screenshots/             # 文档：服务启动与 curl 自测示意
│   ├── service.png
│   └── test.png
├── service/                 # Python FastAPI 侧车服务
│   ├── .env.example
│   ├── requirements.txt
│   ├── requirements-ml.txt
│   ├── run.py
│   ├── app/
│   │   └── stats_backends/   # 统计存储：sqlite / mysql
│   └── scripts/
│       ├── init_stats_mysql.sql
│       └── init_stats_mysql.py
│       ├── train_sklearn.py
│       ├── download_embedding_model.py
│       └── download_embedding_model.sh
└── wordpress/baby-anti-spam/
    └── baby-anti-spam.php # WordPress 插件

关键配置：

| 变量 | 说明 |
|------|------|
| `SPAM_HOST` | 监听地址，同机建议 `127.0.0.1` |
| `SPAM_PORT` | 端口，默认 `8765` |
| `SPAM_API_SECRET` | **单密钥模式（兼容旧版）**：未配置 `SPAM_API_KEYS` 且未配置 `SPAM_API_KEYS_FILE` 时，仅此密钥有效，等价于 name=`default`、不限流（`max_rpm=0`）。与 WP 插件里填写的密钥一致 |
| `SPAM_API_KEYS` | **多密钥**：JSON 数组。每项为 `name`（唯一，用于统计与限流分组）、`key` 或 `secret`（与请求头一致）、`max_rpm` 或 `rpm`（每分钟最大请求数，`0` 表示不限制）。与 `SPAM_API_KEYS_FILE` 合并时：**先读文件条目，再追加本变量** |
| `SPAM_API_KEYS_FILE` | 可选，指向 JSON 文件，根节点为与上表相同结构的**数组**。文件必须存在，否则进程启动失败 |
| `SPAM_MODEL_PATH` | 训练得到的 `*.joblib` 路径；留空则取决于 `SPAM_FALLBACK_RULES` |
| `SPAM_FALLBACK_RULES` | 无模型文件时是否启用内置极简规则（演示用）；生产训练后应设为 `false` 并配置 `SPAM_MODEL_PATH` |
| `SPAM_LABEL_THRESHOLD` | 可选，默认 `0.8`。`spam_score` ≥ 此值时 JSON 中 `label` 为 `spam`，否则为 `normal` |
| `SPAM_DFA_ENABLED` | 默认 `true`。为 `true` 时使用 `dfa-python-filter/keywords` 做敏感词检测；命中则直接 `spam_score=1`、`detail=dfa_sensitive`（早于 sklearn） |
| `SPAM_DFA_KEYWORDS_PATH` | 可选，自定义敏感词文件路径；留空则用 `service/dfa-python-filter/keywords` |
| `SPAM_NON_CHINESE_FLOOR_ENABLED` | 默认 `true`。为 `true` 时若合并后的 author/email/url/text 中**无任何 CJK 表意字符**（主要针对中文训练语料），则将 `spam_score` **至少**抬到 `SPAM_NON_CHINESE_SPAM_FLOOR` |
| `SPAM_NON_CHINESE_SPAM_FLOOR` | 默认 `0.9`。与上项配合，在「无中文」评论上与 sklearn / 规则分取 `max` |
| `SPAM_STATS_ENABLED` | 默认 `true`。为 `true` 时记录每次**成功**返回的 `/v1/classify` 请求与响应（失败 / 401 不落库），并允许 `/v1/mark-spam` 写入 `spam_marks` 表 |
| `SPAM_STATS_BACKEND` | `sqlite`（默认）或 `mysql`。选 `mysql` 时需安装 `pymysql`（已在 `requirements.txt`）并配置下方 MySQL 变量 |
| `SPAM_STATS_DB_PATH` | 仅 `sqlite`：数据库文件路径；留空则为 `service/data/stats.sqlite`（已加入 `.gitignore`） |
| `SPAM_STATS_MYSQL_HOST` / `SPAM_STATS_MYSQL_PORT` | 仅 `mysql`：默认 `127.0.0.1` / `3306` |
| `SPAM_STATS_MYSQL_USER` / `SPAM_STATS_MYSQL_PASSWORD` | 仅 `mysql`：连接账号（`user` 必填） |
| `SPAM_STATS_MYSQL_DATABASE` | 仅 `mysql`：库名（必填），默认示例 `baby_spam_stats` |
| `SPAM_STATS_MYSQL_CHARSET` | 仅 `mysql`：默认 `utf8mb4` |

系统服务启动截图：

wp插件配置：

项目地址：https://anti-spam.zhongxiaojie.cn

代码地址：https://cnb.cool/oba.by/baby-wp-anti-spam

说明：如果自己不想训练数据，下载发布版的spam_pipeline.joblib 放入指定目录下配置服务启动即可，baby-anti-spam.zip 为wp插件。

训练耗时大约11分钟：