皖月清风的个人博客

月度总结 2026-07-27~08-27：AIGC 平台安全攻坚、聚合聊天与 RimWorld 模组爆发本文由 dsV4f 阅读 commit 记录生成（覆盖 GitHub + Gitee 全部仓库） 本文归档 2026-07-27 ~ 2026-08-27 一个月的提交记录。其中 Gitee 上的 5 个仓库（后端/前端/部署/聚合聊天/AI Agent，约 230+ commit）都是公司（寻雷科技）的跨境电商 AIGC 平台，属实习工作内容、不归个人所有；个人产物在 GitHub——包括博客更新与RimWorld 模组（8 个个人模组仓库）。需要说明：8/26-27 的模组提交虽密集，但主要是个人的创意工坊发布工作。 目录（涉及仓库一览） 归属 仓库 类型 本窗提交量 公司 e-commerce-backend 平台后端（Go/GoZero） ~65 公司 e-commerce-frontend 平台前端（React/Taro） ~49 公司 ecf-main-deploy 前端...

Go如何实现“等待 100 个 goroutine 完成，但最多等待 3 秒“context取消1234567891011121314151617181920212223242526272829303132333435363738package mainimport ( "context" "fmt" "sync" "time")func main() { var wg sync.WaitGroup // 创建一个 3 秒后自动取消的 Context ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() // 确保在 main 退出时释放资源 for i := 0; i < 100; i++ { wg.Add(1) go func(id int) { defer wg.Done() // 模拟工作：随机耗时 1-5 秒 workTi...

实习第一个月总结：从校园到企业的AIGC实战之旅本文章由AI阅读commit记录生成，效果感觉一般，意淫了不少我的想法XD 2026年6月25日到7月25日，我在厦门寻雷科技完成了第一个月的实习。这一个月里，我深度参与了一个电商AIGC平台的开发，同时接触了前端（React/Taro）和后端（Go/GoZero），算是真正从”写demo”进入了”做产品”的阶段。 项目概览实习所在的项目是一个跨境电商AIGC内容生产平台，核心是用AI帮助商家生成营销视频、管理素材。技术栈方面： 后端：Go + GoZero 微服务架构，包含 gateway / platform / aggregation / material 等多个服务 前端：Monorepo 架构（pnpm workspace），PC端用 React + Vite，H5用 Taro，App端用 Capacitor AI能力：接入寻雷Bernini、DeepSeek等多个AI服务商 第一个月我提交了大约 40+ 个 commit，覆盖前端和后端，主要集中在以下几个方向。 ...

一、笛卡尔积 × vs 自然连接 ⋈很多新手容易混淆，先划重点： 笛卡尔积 (R×S)：只是把两张表所有行两两配对，不做筛选、不合并同名列； 自然连接 (R \bowtie S)：先做笛卡尔积 → 再自动筛选同名列值相等 → 再删掉重复的同名字段，是带条件、去重复列的笛卡尔积。 前置基础：表结构约定设关系（二维表） (R(A,B))：属性列 A、B (S(B,C))：属性列 B、C公共列：B（同名同类型，自然连接的匹配键） 二、笛卡尔积怎么算定义若 (R) 有 (m) 行，(S) 有 (n) 行，笛卡尔积 (R×S) 有 (m×n) 行；列 = R全部列 + S全部列，同名列会重复保留。 举例实操设：表R A B a1 b1 a2 b2 表S B C b1 c1 b3 c2 计算 R×S（笛卡尔积）把R每一行，分别拼接S每一行： R第一行(a1,b1) + S第一行(b1,c1) → (a1,b1,b1,c1) R第一行(a1,b1) + S第二行(b3,c2) → (a1,b1,b3,c2) R第二行(a2,b2) ...

在数据库中，产生数据不一致的根本原因是（ ）。A．数据存储量太大B．没有严格保护数据C．未对数据进行完整性控制D．数据冗余答案：D解析：数据冗余是根本原因，多副本数据修改不同步会产生不一致；完整性控制是解决办法，不是根源。 层次模型不能直接表示（ ）。A． 1 ：1 关系B．1 ：m 关系C． m ：n 关系D．1 ：1 和 1 ：m 关系答案：C解析：层次模型为树形结构，仅支持 1:1、1:m，无法直接表达 m:n 多对多关系。 关系运算中花费时间可能最长的运算是（ ）。A．投影B．选择C．笛卡尔积D．除答案：C解析：笛卡尔积会将两张表所有元组全部交叉匹配，数据量膨胀极快，开销远大于选择、投影、除运算。 数据库中，数据的物理独立性是指（ ）。A．数据库与数据库管理系统的相互独立B．用户程序与 DBMS 的相互独立C．用户的应用程序与存储在磁盘上数据库中的数据是相互独立的D．应用程序与数据库中数据的逻辑结构相互独立答案：C解析：物理独立性：磁盘上物理存储结构改变，上层应用程序无需修改；D 选项描述的是逻辑独立性。 关系模型中，一个关键字是（ ）。A．可由多个任意属性组成B．至多由...

每日推歌 数据库三级模式中，模式 / 内模式映像保证数据的（）A. 逻辑独立性 B. 物理独立性 C. 分布独立性 D. 存储独立性答案：B解析：模式是全局逻辑视图，内模式是物理存储视图；模式 / 内模式映像定义逻辑与存储的对应关系，修改存储结构（内模式）无需修改应用程序，保证物理独立性；外模式 / 模式映像保证逻辑独立性。 数据库三级模式：模式、外模式、内模式（DBMS标准三层架构）一、核心总览（三层，两级映像） 外模式（子模式/用户视图） → 面向应用/用户 模式（概念模式/全局逻辑视图） → 全库整体逻辑结构 内模式（存储模式） → 物理磁盘存储结构 两层映射：外模式↔模式、模式↔内模式，实现逻辑独立性、物理独立性。 1. 模式（概念模式 Concept Schema）定义整个数据库全部数据的全局逻辑结构、完整描述，是数据库所有表、关系、约束、实体联系的统一视图。 特点 唯一：一个数据库只有1个模式 逻辑层：不关心数据怎么存在磁盘，只描述数据有什么、关系是什么 包含：所有表、字段、数据类型、主键外键、索引逻辑定义...

在 Java 中，方法和属性的访问控制修饰符有 private、protected、public 和 default。 设 Point 为已定义的类，创建 Point 对象 a 的语句是： 答案： Point a = new Point(); 为类 Point 定义一个没有返回值的无参数方法 move()，如果想通过类名访问该方法，则该方法的声明为： 答案： public static void move() 使用 SimpleDateFormat 类对日期进行格式化，显示 “16 时 30 分 15 秒” 格式的语句为： 答案： SimpleDateFormat sdf = new SimpleDateFormat("HH时mm分ss秒"); 设有变量 a 和 b，使用 Math 类中的方法计算 a 的 b 次幂的语句为： 答案： Math.pow(a, b) 假设 s = "Java String"，写出下列操作的输出结果： 操作 输出结果 s.toUpperCase() JAVA STRING s.to...

fd 是什么1. 全称File Descriptor，文件描述符 2. 核心一句话Linux 下一切皆文件：普通文件、TCP连接、UDP套接字、管道、终端、socket、定时器，在内核里全部统一当成文件管理，内核给每一个打开的资源分配一个非负整数编号，这个编号就是 fd。 3. 举最简单例子程序启动默认自带 3 个 fd： 0：标准输入 stdin（控制台输入） 1：标准输出 stdout（打印日志） 2：标准错误 stderr（报错信息） 你打开一个文本文件，操作系统返回数字 3，那这个文件的 fd=3；建立一条TCP客户端连接，返回 4，这条网络连接 fd=4。 4. fd 存在在哪？每个进程单独维护一张 文件描述符表： key：fd 数字 value：指向内核全局的文件对象（socket/文件/管道） 不同进程的 fd 互不干扰，进程A的fd=3 和进程B的fd=3 是完全不同的资源。 5. 关键特性（面试必考点） 资源占用，有上限系统通过 ulimit -n 限制单个进程最大fd数量，默认一般 1024。...

filebeat是beats的一个组件。GMP相关同一时刻：一个 M 只能绑定一个 P，一个 P 也只能被一个 M 使用；生命周期上：M 和 P 不是永久一对一绑定，会因阻塞、抢占、空闲切换动态解绑、重新配对；核心约束：M 执行 G 的前提是临时持有 P，而非终身绑定。 slice 不是线程安全的多个 goroutine 并发读写同一个 slice，一定会出现数据竞争、结果异常、panic。这首歌好听，推荐一下啊【ナースロボ＿タイプT】あの会話の覚書【漣音】 redis 排行榜应该用哪个数据结构ZSet【有序集合】，天然适配排序、分值、去重、分页、排名查询，是 Redis 做榜单的最优解。元素唯一：成员（member）不可重复，天然防重复上榜按分值排序：根据 score 自动升 / 降序排列，对应分数、热度、时间高效排名查询：查询名次、区间分页、查某人排名时间复杂度极低支持分数更新：直接修改 score，集合自动重排 1234567891011121314151617# 1. 添加/更新成员分数（上榜/加分）ZADD rank 99 "user1" ...

有关扩容，假如在数据量到达阈值时直接开新的哈希表进行扩容，那不会导致那一次的 set 操作用时特别久吗？有什么方案能保证这次 set 不会超时吗？一次性全量迁移确实会造成单次 set 卡顿、超时，业界分「基础扩容」「渐进式扩容」「分片扩容」三类方案解决，以 Java HashMap、Go map、Redis 为例逐一说明。 一、先讲原生一次性扩容（问题根源）流程 元素数量达到负载因子阈值（容量 × 负载因子） 本次 put/set 触发扩容：新建2倍容量数组 一次性遍历原数组所有节点，重新计算哈希、迁移到新数组 本次操作结束 缺点 数据量越大，迁移耗时越长，单次请求阻塞，高并发/接口场景极易超时、毛刺严重。 线程不安全场景下还会引发并发死循环（Java JDK1.7 HashMap 经典问题）。 二、主流解决方案（按落地场景划分）方案1：渐进式扩容（增量迁移，最常用）核心思想：不把所有数据迁移压在一次操作里，拆分迁移工作量，分摊到后续每一次读写请求。代表实现：Java 8 HashMap、Go 内置 map、Redis 哈希结构。 执行流程 触发扩容：新建新数组，...