今天是第11个“中国航天日”。清华大学深圳国际研究生院(下称“清华SIGS”)24日发布消息称，清华SIGS联合中国自然资源航空...

  近日，中国农业科技国际交流协会果树分会成立大会暨未来果树产业发展研讨会在郑州召开。15家农业科研院所的专家学者和企业代表齐聚一堂，共谋果树产业国际化发展新路径。会议选举产生...

这算是给这个东西写的第二篇正式的文章，本来我的想法很简单，做一个简单的前后端分离的系统来完全替代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/<database>
# 注意：当前定向清理实现依赖 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 <no-reply@zhongxiaojie.cn>"
#
# 评论回复邮件通知（前台回复他人评论时）
# COMMENT_REPLY_NOTIFICATION_ENABLED=1
# COMMENT_REPLY_EMAIL_FROM="obaby <no-reply@zhongxiaojie.cn>"
# 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=/

# 

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

  

  评论： ×0

---

• 一切都是表象

  

  评论： ×0

---

• 二次元踢踏舞

   

  评论： ×0

---

• 跳舞？不会啊
  评论： ×0

---

• 还要继续减呢~~

  

  评论： ×0

---

列表头像：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

在现代前端生态中，npm 包发布流程的安全性越来越重要。

传统的发布方式通常依赖长期有效的 npm token，一旦泄露，攻击者就可以直接发布恶意版本，带来严重的供应链风险。为了解决这一问题，npm 在 2025 年 7 月份推出了 Trusted Publishing（可信发布） 机制。

什么是 Trusted Publishing？

Trusted Publishing 是 npm 已正式推出基于 OpenID Connect (OIDC) 的可信发布功能。该功能允许使用 OpenID Connect (OIDC) 进行身份验证，直接从 CI/CD 工作流安全地发布 npm 包，从而减少管理长期令牌的需求。

借助可信发布，现在可以

• 无长期 token：不需要在仓库中保存 npm token
• 消除令牌安全风险：无需在 CI/CD 环境中存储、轮换或意外暴露 npm token。
• 短期凭证：每次发布时动态签发，自动过期
• 绑定 CI 身份，建立加密信任：发布权限与 GitHub 仓库/工作流强绑定，每次发布都使用短期、特定于工作流的凭据进行身份验证，这些凭据无法被泄露或重复使用。
• 降低泄露风险：即使 CI 配置泄露，也难以滥用
• 自动获取来源证明：使用可信发布时，npm CLI 默认发布来源证明。--provenance不再需要该标志。

传统发布方式的问题

在 Trusted Publishing 出现之前，常见流程如下：

1. 在 npm 上生成一个 Access Token
2. 将 token 存入 GitHub Secrets（如 NPM_TOKEN）
3. 在 CI 中执行 npm publish 进行发布

问题在于 token 通常是长期有效，一旦泄露，攻击者可以进行发布恶意版本等操作。

现在 npm 限制生成 token 最长有效期为 90 天，还使用这种方式会经常需要轮换 token。

Trusted Publishing 的工作原理

Trusted Publishing 会在 npm 和你的 CI/CD 提供商之间建立信任关系。

当你为你的包配置可信发布者后，npm 将只接受来自你已授权的特定工作流的发布。

Trusted Publishing 基于以下流程：

1. GitHub Actions 在运行时向 npm 发起身份请求（OIDC）
2. npm 验证该请求是否来自可信仓库
3. 如果匹配配置，签发一个短期访问令牌
4. CI 使用该令牌执行 npm publish

整个过程：

• 无需手动管理 token
• 每次发布都是一次“临时授权”

设置 Trusted Publishing

我也是在发布 docsify-footnotes时发现 token 不可用了，此处以它为例：

1. npm 侧配置

进入 npm 包的 Settings页面，就可以看到Trusted Publisher，并且需要选择publisher，支持GitHub Actions、GitLab CI/CD 和CircleCI。

我的仓库在 GitHub，所以选择GitHub Actions，需要配置Organization or user、Repository和Workflow filename，这三个都是必填项。

GitHub 用户名或组织名称 Organization or user：sy-records
仓库名称 Repository：docsify-footnotes
工作流文件名 Workflow filename：publish.yml

点击Set up connection保存即可

2. GitHub Actions 配置

保存之后需要修改对应的 action yml 文件，需要将所需的 OIDC 权限添加到你的工作流中：

permissions:
  id-token: write  # Required for OIDC
  contents: read

关键要求是id-token: write需要获得相应的权限，才能让 GitHub Actions 生成 OIDC 令牌，这是一个完整例子：

name: Publish Package

on:
  push:
    tags:
      - 'v*'

permissions:
  id-token: write  # Required for OIDC
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: '24'
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm run build --if-present
      - run: npm test
      - run: npm publish

因为我的几个 npm 仓库都采用的 复用 actions，所以只需要修改加上permissions和移除写入 npm token 就可以使用了，见 commit。

发布成功后的邮件通知也会增加说明 GitHub Actions 的信息。

Hi sy-records!

A new version of the package @sy-records/docsify-footnotes (2.3.0) was published at 2026-04-21T02:48:22.069Z from GitHub Actions: https://github.com/sy-records/docsify-footnotes/actions/runs/24701393194/attempts/1 (triggered via a "push" event on git ref "refs/tags/v2.3.0").
The shasum of this package is 8136f65cb7d651d4b3671290b7c16da4cac71b24.

If you have questions or security concerns, you can contact us at https://www.npmjs.com/support.

Thanks,

The npm team.

需要注意的是 Trusted Publishing 需要 npm CLI 版本 11.5.1 或更高版本以及 Node 版本 22.14.0 或更高版本。

Trusted Publishing 是 npm 在供应链安全方向的重要升级，建议所有开源项目逐步迁移。

车å�‹ä»¬ï¼Œé«˜å¾·è½¦æœºç‰ˆ 2026 年度力作——9.1.87 稳定版 æ�¥äº†ï¼�这次版本主打一个 “稳â€�与“çœ�心â€� ，堪称闭眼入的 养�级 导航。ä¸�仅视觉效果大幅进化，实用性也拉满，让你的车机导航体验全é�¢å�‡ç»´ï¼�

核心亮点，一眼��

• 红绿ç�¯â€œæ�¢è£…â€�大å�˜æ ·ï¼š ç•Œé�¢ç¾Žå­¦å…¨é�¢å�‡çº§ï¼�æ��ä¾› 3 ç§�个性化背景（ç»�典默认ã€�日照金山ã€�白云山峦）和 2 ç§�字体样å¼�（默认舒适ã€�LEDæ•°ç �风），æ�­é…� 2 ç§�布局，沉浸å¼�导航看ç�€å°±æ˜¯ä¸€ç§�享å�—。
• 显示éš�心调，拒ç»�é�®æŒ¡ï¼š 针对ä¸�å�Œå°ºå¯¸çš„车机å±�幕，新增 4 æ¡£ DPI 调节（新手选 180 DPI 最稳妥），还有 3 æ¡£ç�¯ä½“大å°�，轻æ�¾æ‰¾åˆ°æœ€èˆ’æœ�ã€�最ä¸�挡视线的显示效果。
• 实用主义至上： 播报精简，专注于路线引导，让你å�ªå�¬è¯¥å�¬çš„，开车ä¸�分心。

安装必读（��机必看）

• 针对è€�旧车机： 如果你的车机系统较è€�或签å��å�—é™�（特别是安å�“9/13/15系统），建议优先下载 “é”�14兼容包â€�，能显著æ��高安装æˆ�功率ï¼�
• 比亚迪车主请注æ„�： 安装失败怎么办？ä¸�用慌，多试几个版本。文件å��带 “共存版â€� 的包，是专门为无法覆盖安装的è€�车机准备的，é�žå¸¸é€‚å�ˆå°�鲜。
• DPI 调节å°�技巧： 列表里没找到对应选项？果断选 180 DPI，这是最通用的ä¿�底选择。竖å±�车å�‹å�¯ä»¥ç•™æ„�找 “主竖横竖包â€� 版本，体验更佳。
• 功能预告： 本次版本暂未加入车é�“级导航，别急，这个é‡�磅功能预计会在å�Žç»­çš„大版本中回归，敬请期待ï¼�

版本å�ƒå�ƒä¸‡ï¼Œé€‚å�ˆè‡ªå·±è½¦æœºçš„æ‰�是最好的。花点时间多试几个包，找到你的专属 黄金组� ，就能享å�—这份长久的稳定与舒适。

下载地�

链接：https://pan.quark.cn/s/a6c2e947f35d?pwd=hDnn

抓紧时间上车，开�你的养�级导航之旅�

此《附释文互注礼部韵略》是宋代官修韵书《礼部韵略》的注释本。全书分作：上平声、下平声、上声、去声、入声五卷。收录约9564字，每字下先列官注，后附互注及新增释文，中间用“释”隔开，以示区别。前附《韵略条式》记录官方牒文和程文规范与避讳。此为宋绍定三年藏书阁刊本。