踌躇良久，始终没有下定决心是不是要写这么一篇东西。元旦之前就看到大家写的各种年终总结，图文并茂，各种奇技淫巧，甚至好多人已经连 ai 都用上了。

有的人又写的面面俱到，每当看到这种类型的总结的时候，总是让我自惭形秽。当然，前段时间，看到似水流年发布的 wp 插件时年鉴，感觉这总结的东西总算是有了。于是也安装了一下，点击这里查看。但是鉴于 wp 主题以及插件的各种问题，在阅读量的处理以及其他的一些细节性的东西的处理上稍微少了那么点意思。

当然，不是不信赖咱们博友的水平，只是我这自定义的内容实在太多了，专门来做适配意义其实并不大。于是，这件事情又搁置了。

恍恍惚惚，一眨眼，元旦假期已经过完了，上午的时候忽然想到了 wp 自带的api，那何部直接通过 api 来统计各种数据，于是一番折腾之后，就拿到去年的统计数据了。也曾想过直接让 cursor 连数据库，但是数据库在家里的 mac mini 上，从外面往里连就有点麻烦了。

  WordPress 博客 2025 年度数据分析报告
============================================================

 文章统计
  • 总文章数: 137 篇
  • 文章总评论数: 0 条
  • 总字数: 208,655 字

   按月发布统计:
    2025-01: 10 篇, 9,008 字
    2025-02: 18 篇, 27,449 字
    2025-03: 19 篇, 26,400 字
    2025-04: 16 篇, 22,751 字
    2025-05: 15 篇, 17,964 字
    2025-06: 9 篇, 11,638 字
    2025-07: 1 篇, 1,233 字
    2025-08: 12 篇, 24,933 字
    2025-09: 11 篇, 18,637 字
    2025-10: 5 篇, 8,875 字
    2025-11: 13 篇, 21,495 字
    2025-12: 8 篇, 18,272 字

 评论统计
  • 总评论数: 7451 条
  • 评论用户数: 264 人

 评论用户排行榜 (Top 20)
  排名     用户名                  评论数        邮箱
  ------------------------------------------------------------
  1      obaby                3607       (无邮箱)
  2      爱看                   208        (无邮箱)
  3      似水流年                 160        (无邮箱)
  4      小彦                   149        (无邮箱)
  5      花非花                  128        (无邮箱)
  6      dujun                112        (无邮箱)
  7      acevs                110        (无邮箱)
  8      Vind                 109        (无邮箱)
  9      满心                   100        (无邮箱)
  10     大致                   99         (无邮箱)
  11     皇家元林                 97         (无邮箱)
  12     刘郎                   94         (无邮箱)
  13     网友小宋                 92         (无邮箱)
  14     紫慕                   85         (无邮箱)
  15     全局变量                 76         (无邮箱)
  16     XIGE                 69         (无邮箱)
  17     粽叶加米                 69         (无邮箱)
  18     LiuShen              67         (无邮箱)
  19     文案姐笔记                65         (无邮箱)
  20     ymz316               57         (无邮箱)

排名	用户名	评论数	博客地址
1	爱看	208
2	似水流年	160	https://my1981.cn/
3	小彦	149	https://note-star.cn/
4	花非花	128	https://www.941741.xyz/
5	dujun	112	https://dujun.io/
6	acevs	110	https://acevs.com/
7	Vind	109	https://vindlog.com/
8	满心	100	https://zhoutian.com/
9	大致	99	https://pewae.com/
10	皇家元林	97	https://hjyl.org/
11	刘郎	94	https://vjo.cc/
12	网友小宋	92	https://xyzbz.cn/
13	紫慕	85	https://90zm.net/
14	全局变量	76	https://ilogs.cn/
15	XIGE	69	https://www.shitoucuo.com
16	粽叶加米	69	https://www.wordpace.com/
17	LiuShen	67	https://www.liushen.fun/
18	文案姐笔记	65	https://www.5186a.com/
19	ymz316	57	https://hollowman.cn/
20	keyle	55	https://vrast.cn/
20	Jeffer.Z	55	https://www.jeffer.xyz/

代码地址：https://gitee.com/obaby/baby-wp-data-analysis-tool

去年的访问统计：

博客数据也就是这个样子了，不知什么原因，各大搜索引擎并没有多少来量，所以，有就有没有就没有吧。毕竟这个东西不是生活的全部，兴趣爱好玩成了这个样子，好坏其实都没那么关键。而至于生活工作什么的，越来也没追求了，降薪、降职，早就成了常态，不在其位不谋其政，有段时间一度以为可能要离开了，自己也没想到还能再坚持这么长的时间。

古人说的好，好死不如赖活着，至于底线这个东西，现在所剩也不多了。以前的时候总是说，再怎么样就走了，现在即使这样了都没走。也觉得自己挺没羞没臊的。只是目前还有份工作，还能每个月拿到点工资，似乎也将就的过去，得过且过。

人生这个东西，对我来说从来没什么一帆风顺，这两年变相的再走下坡路了。不过，到现在的职级，应该也算是到底了。现在依然没了任何的管理职能，其实也蛮好的，做好自己的东西就完了，剩下的也不是自己该去考虑的。公司让再研发中推广各种 ai 的使用场景和频次，当然，目的也很简单，只是，当被这种毫无技术难度的琐事困住的时候，不应该每天只去处理这些垃圾。也该去做点别的事情，至于工作的事情，每天做好份内的事情就足够了，毕竟这不是你的事业，他们也没想让你把这个东西当成自己的事业来干。

元旦前还有另外一件事情也搁置了，那就是 google playstore 的上架，节前折腾了一段时间。最后因为忙于开发新版本，这件事情也就再也没了跟进。不是不做了，只是时间也的确有限，捉襟见肘。每天晚上去开发一些新的功能以及测试修复 bug，就花掉了很多的时间。当然，家里的效率要比在公司高很多，毕竟两块 4k 分辨率的显示器能解决频繁切换窗口的问题。公司项目，也仅仅限于在那块 13 英寸的 mbp 上进行开发，速度慢就慢吧。

严格意义上来说，自己不算是一个合格的产品经理。一不会用各种产品经历的工具，二不会 ui 设计，所以一直到现在闺蜜圈都没有一个好看的 ui。总觉得也是做出点改变的时候了，元旦前开始重新设计和调整整个 app 的色调，ui 以及各种图标。到目前为止个人感觉稍微好看了那么一丢丢，也加入了一些新的功能，包括自定义背景等等。

元旦假期哪里都没去，偶尔带着宝子附近的公园转转，剩下有时间就改 ui 设计图标，写代码。早上也没有太多的事情，睡到自然醒，有时候能到九点多。好长时间没睡到自然醒了。晚上就是运动，节前又请了一天假，为了达成运动目标，31 号跳了一万个绳，剩下几天也是坚持每天达成一万步，因为出去走的少，就只能靠跳绳补上了。

当然，还要抽时间跟华为的应用市场 battle，已经来回三个回合了，都以自己战败为终，这几番折腾下来已经快一个月时间了。

之前为了能在华为应用市场上线 AI 助理的功能，重新申请了应用安全评估，做了手机号验证等功能。现在被驳回给出的答复是，AI 功能，需要进行实名认证，现在任意账号注册就可以使用。然而，我在审核说明已经写了，ai 助理需要验证手机号，虽然能看到但是不能用，需要先验证手机号。

但是，我的解释是徒劳的，他们就认准了这一点，所以下一版发布的时候，华为市场的应用只能强制先验证手机号了。在这种 boss 战中，自己没有任何的优势，甚至连招架的能力都没有，只能听之任之。

而至于 ai，目前还有另外一个想法，基于当前数据使用机器学习来计算预测经期，只是现在还差的有点远，还得继续优化：

虽然做的工作很多，却并不知道最后的结局如何。一切都是未知数，坚持的理由，说来也简单：一件事情一旦开始做了，总是想着能做好。虽然跟其他的所谓的头部的应用比有差距，目标总是有的，做最简单最易用的。之前也想着添加个开屏广告什么的，然而，这个东西加上了的确影响体验，更何况现在没几个用户，加了这个广告挣个几块钱的广告费，不够恶心人的，只能说恶心效果大于实际意义。

现在开发的进度也的确像一场游戏，有的时候真的是能让人破防。这几天在调试 ios 的 iap，uni 官方的文档就那么几行代码，如果说基于那几行代码来实现功能，必然是会失败的。然而，网上关于 uni iap 的问斩又异常的少，偶尔搜到那么一两篇也没什么大用，所以，可能是很多人都在这地方卡住过，但是却从来没有人来说过这些问题。

如果说，25 年最成功的也就只剩下减肥了，从年初到年底一共减掉了 30 斤。减肥的动力来源说出来也的确可笑，一个是为了健康，另外一个主要的原因是为了拍写真。拍写真可能不需要真的能够很瘦，毕竟，都是可以通过修图来实现的。甚至，现在都不需要去拍了，直接找个图片换脸，或者直接 ai 生成效果反而可能会更好。

年初的时候，为了让自己看起来瘦一点，甚至还用过束腰，当然这个东西只是一时捆着有用，放开了之后还是原来的样子。现在，不再需要用这个东西，也能把自己塞到影楼的裙子里了。

去年的时候拍的，当然这个肚肚是 p 过的（p 小了点）。现在甚至能隐约看到锁骨了。

今年，目标不再是 30 了，只需要能再减 20 就可以了。

又何苦在意太多，人生不过是一场 rpg，总是要不断的打怪升级，更何况现在支线任务的 boss 依然出现了，减肥和继续开发推广闺蜜圈。

至于主线任务，现在完全看不清楚，只能走一步看一步，毕竟从来也没办法一条道走到黑。随机而变，伺机而动才是常态。

为什么这个Bug如此狡猾？

直觉背叛：我们直觉上认为 -A 就是 “负的A”，但在位运算中它变成了”A的补码”
测试遗漏：我们测试了正数情况，但对负数的测试不够充分
认知偏差：我们都”知道”补码，但真正用到时却忘了它的存在

你发现下面代码中的问题了吗 ？

1
2
3
4
5
6
7
8
9

// 伪代码：用负数表示反选，正数表示正常选择
bool ShouldSelect(int value, int mask)
{
    if (-value & mask == Mathf.Abs(-value))
    {
        return -value > 0;
    }
    return false;
}

在C#中，A & B 和 -A & B 的区别主要在于对负数处理的不同。让我通过具体案例来说明：

案例演示

1
2
3
4
5
6
7
8
9
10

int A = 5;    // 二进制: 0000 0101
int B = 3;    // 二进制: 0000 0011

// 情况1: A & B
int result1 = A & B;     // 5 & 3
Console.WriteLine($"A & B = {result1}");  // 输出: 1

// 情况2: -A & B  
int result2 = -A & B;    // -5 & 3
Console.WriteLine($"-A & B = {result2}"); // 输出: 3

二进制分析：

1
2
3
4
5
6
7

A = 5:  0000 0101
B = 3:  0000 0011
A & B:  0000 0001  = 1

-A = -5: 1111 1011 (补码表示)
B = 3:   0000 0011
-A & B:  0000 0011  = 3

更多案例

1
2
3
4
5
6
7
8
9
10
11
12

// 案例2
int A2 = 10;  // 1010
int B2 = 6;   // 0110

Console.WriteLine($"{A2} & {B2} = {A2 & B2}");      // 输出: 2
Console.WriteLine($"-{A2} & {B2} = {-A2 & B2}");   // 输出: 6

// 案例3 - 负数和负数
int A3 = -3;
int B3 = -5;

Console.WriteLine($"{A3} & {B3} = {A3 & B3}");      // 输出: -7

背后的意义

1. 补码表示法

• 在C#中，整数使用二进制补码表示
• 正数的补码是其本身
• 负数的补码 = 对应正数的二进制取反 + 1

2. 运算本质

• A & B：对两个数的实际二进制位进行按位与
• -A & B：先计算A的补码（得到-A），再与B进行按位与

3. 实际应用场景

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 标志位检查
[Flags]
enum Permissions
{
    Read = 1,    // 0001
    Write = 2,   // 0010  
    Execute = 4  // 0100
}

// 检查权限
Permissions userPermissions = Permissions.Read | Permissions.Write;

// 正确的方式：直接与操作
bool canRead = (userPermissions & Permissions.Read) != 0;  // true

// 错误的方式：使用负数（无意义）
bool wrongCheck = (-(int)userPermissions & (int)Permissions.Read) != 0; // 结果不可预测

4. 重要注意事项

1
2
3
4

// 注意：-A & B 不等于 -(A & B)
int A = 5, B = 3;
Console.WriteLine($"-A & B = {-A & B}");        // 3
Console.WriteLine($"-(A & B) = {-(A & B)}");    // -1

总结

• A & B 是直接的按位与运算，结果可预测
• -A & B 涉及补码转换，结果取决于负数的二进制表示
• 在实际编程中，应避免对负数进行无意义的位运算，除非明确理解补码机制
• 位运算通常用于标志位、掩码操作等场景，应保持操作数的明确性和可读性

当你需要将Git项目迁移到新位置、更换托管平台或彻底重置版本控制时，就很有可能需要这些知识。

项目迁移的需求比你想的要常见得多。比如你从 GitHub 搬到公司内网的 GitLab，或者将旧项目里的子模块拆分成独立服务，甚至是因为一不小心把密钥上传了，想清理历史记录重开一个干净的新仓库。这些场景下，你就需要用对 Git 的“迁移姿势”。
很多开发者觉得迁移麻烦，其实只要理解 Git 本质上是一个内容寻址的“版本快照系统”，你就会发现迁移不外乎两件事：“我要保留什么？”、“我要丢弃什么？”这篇指南就是围绕这两个问题展开，让你从容应对各种 Git 迁移需求。

对了，你可以根据下面的决策树，决定你想阅读的部分，实践过程中有疑问欢迎探讨。

迁移决策树
保留历史？ → 用--mirror克隆
只需最新代码？ → 移除.git后重建
需要部分历史？ → git filter-repo

完整迁移方案（保留历史记录）

如果你想把整个仓库搬家，不想丢掉任何东西（包括分支、Tag、历史提交、远程设置等），--mirror 是你最好的选择。它就像一张完整备份快照，把 .git 中的所有引用和配置都复制一份，适合对原始仓库做“全量克隆”。
这个方法尤其适合从一个平台搬到另一个平台，比如从 GitHub 搬到 Gitee 或 GitLab。注意，推送时也要用 --mirror，否则有些引用（如远程分支）不会同步过去。如果原项目的默认分支是 master，而新仓库默认使用 main，也可以中途重命名。总之，这种方法是最“保险”的迁移方式，适合保守型开发者。

1
2
3
4
5
6
7
8
9
10

# 1. 克隆原仓库（保留所有分支和标签）
git clone --mirror https://github.com/user/old-repo.git
cd old-repo.git

# 2. 推送到新仓库
git push --mirror https://gitee.com/user/new-repo.git

# 3. 本地切换新源（适用于已有工作区）
git remote set-url origin https://new-repo-url.git
git push -u origin --all

纯净迁移方案（不保留历史）

有时候，我们并不想背着历史包袱重新开始，尤其是当你意识到旧代码已经乱成一团，或者包含了不该泄露的敏感信息。这时，你可以选择删除 .git 目录后重建仓库。这种方式非常直接粗暴，也非常“轻量”：只保留代码内容，丢掉所有版本历史，就像从来没用过 Git 一样重新开始。
当然，这种方法的风险也在于你将彻底丢失所有变更记录、作者信息和 Tag。所以如果是团队项目，建议先沟通好再操作。如果你想只保留某一分支最近的提交，也可以用 git clone --depth 1 进行浅克隆，然后重新初始化。

1
2
3
4
5
6
7
8
9
10
11

# 1. 解除当前版本控制（保留文件）
rm -rf .git

# 2. 初始化新仓库
git init
git add .
git commit -m "初始提交"

# 3. 关联远程仓库
git remote add origin https://new-repo-url.git
git push -u origin master

高级迁移技巧

大型单体仓库逐渐拆分成微服务或子模块，是很多团队发展的必经阶段。这时候你可能就会想：我只关心某个子目录的内容，能不能把它独立成一个仓库，还保留它的提交历史？当然可以，这就要用上 Git 高级利器 —— git filter-repo。
filter-repo 可以非常高效地把某个目录及其历史提交“提取”出来，形成一个全新的独立仓库，不仅文件内容干净，连提交记录都只保留相关部分。比如把 src/module-a 提成一个新仓库，并作为根目录使用，就可以用 --subdirectory-filter。它的效果比 filter-branch 快百倍，也更不容易出错。唯一要注意的是，它需要额外安装，建议在克隆出来的副本里操作，避免污染原始仓库。

1. 迁移指定分支

   1	git push new_remote local_branch:remote_branch

2. 迁移子目录

   1	git filter-repo --subdirectory-filter my-subdir

3. 清理历史大文件

   1	git filter-repo --strip-blobs-bigger-than 10M

迁移后必检项

1. 验证分支/标签是否完整：

   1	git branch -a && git tag -l

2. 检查文件完整性：

   1	git fsck --full

3. 更新CI/CD配置：

   • Jenkins/GitLab CI中的仓库地址
   • Webhook设置

避坑指南

⚠️ 敏感信息处理
迁移前使用git secret scan扫描密钥/密码
推荐工具：git-secrets

⚠️ LF/CRLF问题
这是 Git 世界里最容易被忽略、却最容易“把人整崩溃”的问题之一。如果你在 Mac 上开发，换行符是 LF，而 Windows 默认是 CRLF。于是你 clone 一份代码，结果一提交，全仓库变成了“修改”状态，其实只是换行不一致。
为了避免这种尴尬情况，Git 提供了 core.autocrlf 设置。Windows 用户推荐设置为 true，它会在 checkout 时把 LF 转成 CRLF，提交时再转回；macOS/Linux 用户建议设置为 input，提交时强转 LF，保持一致。除此之外，还建议在仓库根目录建一个 .gitattributes 文件，强制设置文件类型的换行行为。统一格式不仅能避免多人协作混乱，还能让你在 PR、diff 中更容易看出实际修改。

Windows用户迁移后执行：

1
2

git config core.autocrlf input
git reset --hard

⚠️ 高危警告（使用前必读）

你知道吗？全球有数以万计的 Git 仓库曾经不小心泄露了密钥、数据库密码甚至生产环境的 API token。别以为“只是试试”，Git 会把你每一次 commit 的文件都记录在历史中，即使后面删除，历史里也还在。
为了防止“祸从提交起”，推荐在迁移前使用安全扫描工具：AWS 出品的 git-secrets 可以在你提交前实时检测敏感关键词，truffleHog 更是“暴力搜索”连编码过的 token 都能挖出来。如果发现确有泄露，可以配合 filter-repo 清除掉对应的文件和提交。这一步虽然繁琐，却能挽救整个项目的安全风险，强烈建议纳入你团队的代码审查流程中。

1. 永久性删除

   1 2	- 所有提交历史、分支、标签将被不可恢复地删除！ - 操作前请确认已备份重要版本信息

2. 作用范围

   1 2	+ 仅在当前执行目录及其子目录生效 - 禁止在根目录(/)或家目录(~)运行！可能导致系统崩溃！

3. 敏感操作防护

   1 2 3 4

   # 安全建议：先预览将被删除的目录 find . -type d -name ".git" | while read dir; do echo "[高危] 即将删除: ${dir}" done

附录：补充一个删除.git的安全方案（纯净版）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#!/bin/bash

TARGET_DIR=$(pwd)
CONFIRM=""

# 危险操作二次确认
read -p "⚠️ 即将永久删除 ${TARGET_DIR} 下所有.git目录！确认执行？(y/N) " CONFIRM

if [[ $CONFIRM == "y" || $CONFIRM == "Y" ]]; then
  echo "[安全日志] 用户确认执行删除操作"
  find . -type d -name ".git" -exec echo "删除: {}" \; -exec rm -rf {} +
  echo "操作完成 | 删除时间: $(date)"
else
  echo "操作已取消"
fi

最后，请务必需要注意，任何删除操作前，用git bundle创建完整备份包，可通过git clone backup.bundle恢复历史**