编程 on 洛克里亚的五度博客

理解MySQL的MVCC

Tue, 28 Jul 2026 13:40:09 +0800

我们为什么需要 MVCC ？

没有MVCC（多版本并发控制 Multi-Version Concurrency Control）的情况下，面对数据库事务中"读某一条数据"的行为，我们只能加锁。这个锁可以是共享锁/排他锁，保证"我读的时候没人过来写"，避免脏读（读到和最终结果不一致的数据）。然而一旦加锁，其他线程就要等，一等并发效率就直线下降。

MVCC 的思路是：读的时候不加锁，而是通过"版本"来判断一条数据对我来说能不能读。

每一行数据的三个隐藏字段ba

每一条数据除了业务字段外，还有三个隐藏字段：

DB_TRX_ID   最近一次插入/更新/删除该行的事务id
DB_ROLL_PTR 回滚指针，指向这行数据在 undo log 中的上一个版本
DB_ROW_ID   隐藏主键，仅在表没有定义主键时才会生成

undo log 把同一行数据的历史版本串成一条链，DB_ROLL_PTR 就是链上的指针，出问题时可以顺着它一路往回找老版本。

Read View：读之前先拍个快照

在真正读数据之前，我们会先生成一个快照，叫做 read view。它记录了这几样东西：

m_ids       生成快照那一刻，所有"活跃"（未提交）的事务id列表
min_trx_id  m_ids 里最小的那个id
max_trx_id  系统里下一个将要分配的事务id（也就是目前已知最大事务id + 1）

注意 max_trx_id 不是"当前活跃事务里最大的那个"，而是"还没被任何事务用过的、未来第一个可用的id"——因为事务id是全局递增分配的。

这里要先说清楚一件容易被忽略的事：read view 什么时候生成，在不同隔离级别下是不一样的。

READ COMMITTED（读已提交）：每次执行 SELECT 语句都重新生成一个 read view
REPEATABLE READ（可重复读，MySQL默认）：只在事务内第一次执行 SELECT 时生成一次，之后整个事务复用同一个 read view

这个区别直接决定了"我这次读，能不能看到别人事务提交的新数据"——RC 每次都能看到最新提交的结果，RR 则始终锁定在事务开始时的那个快照上，这也是可重复读名字的由来。

拿到 read view 之后，怎么判断某一行能不能读

现在回到最初的问题：我们要读一行数据，它的 DB_TRX_ID = 200。这条数据被事务200修改过，我们能不能读到它，要按顺序做以下判断：

过家家项目：如何设计抢红包

Sat, 25 Jul 2026 11:09:53 +0800

在我的项目“过家家”里，有一个抢红包的功能。功能类似微信抢红包。

抢红包的基本逻辑

v1（低并发）抢红包时实时使用二倍均值法计算，只使用MySQL

1. 红包创建流程

用户发红包时，指定总金额与红包个数
系统将总金额拆分为指定数量的红包
红包数量约束：
- 最少为 1 个
- 最多不能超过群成员数量

2. 红包金额分配策略

单个红包：不进行随机计算，抢到即获得全部金额
多个红包：采用二倍均值法进行随机分配
- 当前用户最大可抢金额 = 剩余金额 / 剩余人数 × 2
- 实际可抢区间为 [0.01, 最大可抢金额 - 0.01]
  - 下限 0.01 元：保证每个抢到的用户都有收益
  - 上限减 0.01 元：保证剩余红包仍有余额可抢
- 边际示例：10 元红包 2 人分，第 1 人可抢区间为 [0.01, 9.99]

3. 数据持久化与防刷控制

红包创建后入库存储
发红包限流：同一用户 10 秒内仅允许发送 1 个红包，防止手抖误操作

4. 抢红包并发控制

防重复抢：在 redpacket_grabs 表中建立 (userId, redpacketId) 联合唯一索引，确保同一用户对同一红包仅能抢一次
防超卖：采用数据库乐观锁机制
- 更新 redpacket 表时，必须同时满足：
  - remaining_count > 0
  - remaining_amount >= 本次扣减金额

5. 方法缺点

每次请求直接打数据库，导致响应时间没有访问内存快
每次请求都会使用二分均值法计算抢到的金额，并且做超卖判断，比较麻烦

v2 （高并发）红包创建好了就已经固定了抢红包的数量和个数，加入Redis

大致流程

Kafka 学习笔记

Sat, 18 Jul 2026 16:01:26 +0800

偏移量索引

高可用

ISR机制

DB MQ Redis 常见实践

Thu, 16 Jul 2026 22:20:21 +0800

一、读路径：Cache Aside(旁路缓存)

先查 Redis，命中就返回；未命中查 DB，回写 Redis 后返回。

Redis 三件套

问题	场景	解法
穿透	查一个不存在的 key，每次都打到 DB	缓存空值(短 TTL) + 布隆过滤器 + 参数校验
击穿	某个热点 key 过期，瞬间大量请求打到 DB	分布式锁只放一个线程回源 + 逻辑过期(异步重建) + 热点 key 不过期
雪崩	大批 key 同时过期或 Redis 宕机	TTL 加随机抖动 + 多级缓存(Caffeine + Redis) + 熔断降级(Sentinel) + 集群/哨兵高可用

二、写路径：先写 DB，再删缓存

不用"更新缓存"而用"删除缓存"：避免并发写导致的脏数据，也避免为不会被读的数据做无用计算(lazy loading)。

为什么是"先 DB 后删"而不是"先删后写 DB"？ 先删缓存，在写 DB 的间隙可能有读请求把旧值重新加载进缓存，且这个旧值会一直存在直到过期。

但先写后删仍有极小概率不一致(读线程读到旧 DB 值 → 写线程写 DB + 删缓存 → 读线程回写旧值)。兜底方案：

Flutter 相关面试题整理

Wed, 15 Jul 2026 00:46:10 +0800

从互联网整理而来

一、Dart 基础

Dart 的数据类型有哪些？
var、final、const 的区别
Dart 中 null safety 是什么，如何使用？
late 关键字作用与使用场景
Dart 函数可选参数、命名参数、位置参数区别
箭头函数适用范围
Dart 异步：Future、async/await 原理
Stream 与 Future 区别，StreamController 使用
sync*、async*、yield、yield each 作用
Dart 类中 extends、implements、mixin 区别
mixin 有什么限制，能否构造函数传参
抽象类与接口区别
泛型 T、?T、T?、required T 区别
Dart 单例几种实现方式
工厂构造函数 factory 作用
常量构造函数使用条件
级联运算符 .. 原理
空值操作符 ?.、??、??= 用法
Dart 枚举进阶用法，能否自定义属性方法
Isolate 是什么，和线程区别，通信方式
Isolate 共享内存吗，数据传递限制
Zone 作用是什么
Dart 垃圾回收机制
函数一等公民体现在哪里
typedef 作用与场景

二、Flutter 框架核心原理

Flutter 三棵树：Widget、Element、RenderTree 关系
StatelessWidget 和 StatefulWidget 底层差异
State 生命周期完整流程
initState、didChangeDependencies、build、didUpdateWidget、dispose 执行时机
setState 底层更新机制
Widget 为什么是不可变的 immutable
Element 作用，Element 复用逻辑
RenderObject 职责是什么
Key 的作用，几种 Key 区别（ValueKey、ObjectKey、UniqueKey、GlobalKey）
GlobalKey 使用场景与隐患
LocalKey 解决什么问题
Widget 重建流程，哪些情况会触发重建
什么是 const Widget，好处是什么
Flutter 渲染流程：布局、绘制、合成步骤
布局约束流程：Constraints 传递规则
父布局约束如何限制子控件尺寸
RepaintBoundary 作用，何时使用
Layer 树作用，缓存机制
Flutter 与原生 Android/iOS 渲染区别
Skia 引擎作用
Impeller 渲染引擎对比 Skia 优势
Flutter 绘制原理，Canvas、Paint 流程
PipelineOwner 作用
WidgetsBinding、SchedulerBinding 职责
帧调度流程：Vsync、帧回调执行顺序
transientCallbacks、persistentCallbacks、postFrameCallbacks 区别
Flutter 热重载原理，热重启区别
编译模式：debug/profile/release 差异
AOT、JIT 编译区别
Flutter 页面路由底层实现原理

三、布局 & 基础组件

Row Column Flex 布局区别，主轴交叉轴概念
MainAxisAlignment、CrossAxisAlignment 所有枚举值含义
Expanded、Flexible 区别，flex 参数作用
Stack、Positioned 布局规则
Align、Center 底层关系
Padding、Container 内部结构
Container 嵌套过多有什么性能问题
SizedBox、ConstrainedBox、UnconstrainedBox 用途
AspectRatio、FittedBox 缩放逻辑
Wrap 自动换行实现原理
ListView 几种构造方式区别（默认、builder、separated）
ListView.builder 高性能原理，复用机制
ListView 滚动复用失效场景
GridView 使用与性能优化
SingleChildScrollView 嵌套 ListView 报错解决方案
CustomScrollView、Sliver 体系是什么
SliverList、SliverGrid、SliverAppBar、SliverToBoxAdapter 使用场景
SliverPersistentHeader 固定吸顶实现
CustomScrollView 滚动统一原理
Table、DataTable 布局特性
IntrinsicHeight、IntrinsicWidth 性能损耗原因
LayoutBuilder 获取父布局约束场景
MediaQuery 获取设备信息，MediaQuery.of(context) 刷新机制
LayoutId、MultiChildLayout 自定义布局
Flow 高性能流式布局适用场景

四、状态管理

State 自身状态管理优缺点
InheritedWidget 底层原理，数据传递逻辑
InheritedModel 对比 InheritedWidget 优势
Provider 整套库实现原理（ChangeNotifierProvider、Consumer、Selector）
Selector 为什么能精准局部刷新
ChangeNotifier 通知更新机制
StateProvider、FutureProvider、StreamProvider 区别
Riverpod 对比 Provider 改进点
Riverpod 全局状态、自动 dispose、无 context 优势
StateNotifier、AsyncNotifier 使用场景
Bloc 核心概念：Event、State、Bloc/Cubit
Cubit 与 Bloc 区别
BlocProvider、BlocConsumer、BlocBuilder、BlocListener 分工
Bloc 状态单一数据源优势
GetX 状态管理原理，GetController 生命周期
GetX 全局路由、依赖注入实现
GetX 优缺点，存在什么性能隐患
Redux 在 Flutter 中使用逻辑
MobX 响应式原理，Observable、Action、Reaction
大型项目如何选型状态管理方案
跨页面共享状态几种实现方式对比
状态持久化配合状态管理怎么做

五、路由 & 导航

Navigator 1.0 路由栈管理原理
MaterialPageRoute、CupertinoPageRoute 区别
PageRouteBuilder 自定义转场动画
Navigator push/pop/pushReplacement/popUntil 逻辑
路由传参几种方式
Navigator 2.0 核心组件：Router、RouteInformationParser、RouterDelegate
Navigator 2.0 完整路由流程
GoRouter 框架底层封装逻辑
GoRouter 嵌套路由、路由守卫、参数获取
路由栈持久化、页面状态保存方案
底部导航多 Tab 页面状态保持实现
路由拦截、登录鉴权统一处理
原生页面与 Flutter 页面互相跳转路由处理
页面返回监听 WillPopScope、PopScope
深度链接 deep link 适配方案

六、动画

Flutter 动画核心类：Animation、AnimationController、CurvedAnimation
AnimationController vsync 作用，为什么需要 TickerProvider
SingleTickerProviderStateMixin、TickerProviderStateMixin 区别
Tween、Animatable 差值计算原理
显式动画与隐式动画区别
AnimatedContainer、AnimatedOpacity 等隐式动画底层
Hero 共享元素动画实现原理
PageRoute 共享 Hero 流程
CustomAnimation 自定义动画组件
交错动画 Interval 使用
动画性能优化，避免重建
Lottie 动画集成原理，性能注意点
循环动画、反向动画实现
动画暂停、恢复、释放资源处理
自定义路由转场动画

七、网络 & 本地存储

dio 库封装思路，拦截器使用
dio 统一请求头、错误处理、token 自动刷新
取消请求 CancelToken 使用场景
并发请求、超时处理
Json 序列化反序列化几种方式（手动、json_serializable）
fromJson/toJson 生成流程
Freezed 数据模型优势
http 库与 dio 对比
WebSocket 在 Flutter 中使用，重连机制
shared_preferences 底层存储原理
Hive 本地数据库优势，Box 使用
Hive 加密、大数据存储优化
sqflite 数据库操作，事务使用
Isolate 中操作数据库注意事项
文件读写 path_provider 获取路径
图片缓存 cached_network_image 实现逻辑
网络请求缓存策略设计
接口统一异常捕获封装方案

八、原生交互 MethodChannel

MethodChannel、BasicMessageChannel、EventChannel 三者区别
MethodChannel 双向通信完整流程
Flutter 调用 Android 原生代码步骤
Flutter 调用 iOS OC/Swift 步骤
原生主动推送数据给 Flutter 使用哪个 Channel
传参类型限制，复杂对象传递方案
多页面 Channel 单例管理
PlatformView 嵌入原生 View（Android View、iOS UIView）
PlatformView 性能问题与优化
原生页面跳转 Flutter 传参
权限通过原生通道申请方案
混合栈开发：flutterBoost 原理
flutterBoost 页面生命周期同步问题
原生资源与 Flutter 资源冲突处理
通信通道内存泄漏如何避免

九、性能优化专项

Widget 重建常见诱因与规避手段
const 构造优化原理
Key 不合理使用导致的性能问题
ListView 长列表优化方案
图片加载优化：尺寸、缓存、压缩
RepaintBoundary 拆分重绘区域场景
减少 Layer 树层级优化
避免使用 Intrinsic 系列控件原因
动画卡顿排查思路
DevTools 工具使用：性能面板、内存、Widget 检查
内存泄漏常见场景（Timer、Stream、Channel、Animation）
大图片、大量对象内存释放方案
Isolate 处理耗时计算优化 UI
build 方法避免耗时操作
布局嵌套过深优化手段
页面 dispose 资源释放规范
Profile 模式性能排查要点
启动速度优化（包体积、懒加载、预加载）
Flutter 包体积优化方案
滑动卡顿完整排查流程

十、图片、手势、输入、弹窗组件

Image 几种构造：AssetImage、NetworkImage、FileImage、MemoryImage
ImageProvider 缓存机制
Image.network 缓存缺陷，cached_network_image 弥补方案
DecorationImage、FadeInImage 使用
GestureDetector 手势识别原理，多手势冲突
Listener 底层原始手势与 GestureDetector 区别
手势竞争、手势忽略场景
InkWell 水波纹实现原理，必须嵌套 Material
TextField 控制器 TextEditingController 使用
TextField 输入监听、格式化、光标控制
表单 Form、GlobalKey 校验逻辑
ModalRoute、showDialog、showBottomSheet 弹窗原理
弹窗状态共享问题解决方案
Draggable、LongPressDraggable 拖拽实现
Transform 变换不改变布局约束特性

十一、项目工程 & 打包适配

pubspec.yaml 各字段含义，依赖版本约束
本地依赖、Git 依赖、远程依赖配置
pub 依赖冲突解决方法
Flutter 多环境配置（开发/测试/生产）
Flavor 多渠道打包 Android & iOS
Android 打包 keystore 配置，iOS 证书配置
AndroidManifest、Info.plist 权限适配
屏幕适配方案：媒体查询、比例、flutter_screenutil
深色模式适配实现
多语言国际化 intl 库使用
App 图标、启动页配置
Flutter 插件开发流程
平台区分代码编写（dart.io、Platform 判断）
混合开发项目目录结构
CI/CD 自动打包脚本思路
版本号管理升级方案
第三方插件兼容问题处理

十二、进阶底层 & 疑难场景

WidgetsApp、MaterialApp、CupertinoApp 内部结构
ThemeData 主题分发原理，局部主题覆盖
Navigator 上下文与页面上下文区别
context 获取上层 Widget 原理，BuildContext 分类
State 保存在 Element 中，Widget 重建 State 不销毁条件
Offstage、Visibility 控件隐藏区别
AbsorbPointer、IgnorePointer 拦截手势差异
Clip 裁剪控件：ClipRect、ClipRRect、ClipOval 性能
BackdropFilter 模糊控件性能损耗原因
RenderBox 自定义控件完整流程
自定义 RenderObject 实现步骤
自定义 MultiChildRenderObjectWidget
ScrollController 监听滚动、滚动定位
ScrollPhysics 滚动回弹、阻尼自定义
监听应用前后台切换 AppLifecycleState
截屏、屏幕亮度、震动原生能力实现
WebView 插件使用与通信
Flutter Web 编译差异，平台兼容问题
Flutter Windows/macOS/Linux 桌面端适配要点
如何实现全局捕获异常
Timer、StreamSubscription 忘记取消的内存泄漏
列表 item 点击状态保存方案
异步并发竞态条件问题处理
图片大量加载 OOM 解决方案
原生弹窗遮挡 Flutter 页面问题

十三、综合项目面试问答题

讲一下你项目整体架构分层
项目状态管理选型原因
长列表卡顿怎么优化的
多页面共享登录状态如何实现
token 过期统一拦截处理方案
项目混合栈开发遇到哪些坑
图片缓存、网络缓存怎么设计
全局网络加载弹窗、错误页封装思路
项目通用业务组件封装思路
线上卡顿、崩溃排查处理经验
如何实现页面无网络重试逻辑
复杂表单页面状态管理方案
项目包体积优化做了哪些操作
多渠道、多环境配置实现
封装通用 Dio 请求库完整思路

MyBatis 相关面试题整理

Wed, 15 Jul 2026 00:46:10 +0800

Mybatis 执行流程

mybatis-config.xml (总规) ↓ SqlSessionFactory (总管) ↓ SqlSession (服务员) —— 包含所有执行方法 ↓ Executor (大管家) —— 优先查缓存（一级/二级） ↓ MappedStatement (菜谱) —— 持有SQL、参数映射、结果映射 ↓ 输入参数映射 (备菜) → JDBC执行 → 输出结果映射 (装盘) ↓ 返回POJO/集合 (上菜)

Mybatis 是否支持延迟加载

支持，默认不开启

collection fecthType=“lazy”

mybatis配置文件延迟加载 lazyLoadingEnabled

延迟加载的原理

CGLIB创建目标对象的代理对象
调用目标方法 getOrderList
调用对象 invoke 方法
判断 orderList 是否为空
为空，执行SQL
不为空获取结果
封装 orderList

Mybatis 的一级缓存二级缓存用过吗

本地缓存 - 基于 PerpetualCache 本质是一个 HashMap 一级缓存 - 作用域是 session 级别二级缓存 - 作用域是namespace 和 mapper的作用域，不依赖于 session 二级缓存默认关闭 settings name=“cacheEnabled” value=“true” 当某个作用域进行了增删改操作，该作用域下的所有select的缓存将被clear

React 相关面试题整理

Wed, 15 Jul 2026 00:46:10 +0800

从互联网整理而来

一、JS 基础前置

原型与原型链
闭包、闭包引发的内存泄漏场景
同步异步、宏任务微任务执行顺序
Promise 状态、静态方法、链式调用
async/await 原理
深浅拷贝实现与区别
this 指向五种场景
箭头函数与普通函数差异
ES6 解构、展开运算符、剩余参数
var / let / const 区别
CommonJS 与 ES Module 差异
TypeScript 接口、泛型、交叉类型、联合类型
EventLoop 完整执行流程
防抖节流实现原理
纯函数定义与特性

二、React 基础核心概念

React 设计思想与核心理念
虚拟 DOM 是什么，作用与优势
JSX 语法本质，编译产物
JSX 中 {} 可放入哪些内容，不能放什么
React 元素与组件区别
函数组件与类组件区别
纯组件 PureComponent 原理
React 单向数据流含义
props 只读特性，为什么不能直接修改
props.children 有哪些类型
key 的作用，为什么不能用 index 做 key
React 列表渲染注意事项
className 代替 class、htmlFor 代替 for 原因
React 事件绑定与原生 DOM 事件差异
合成事件原理、事件委托机制
阻止合成事件冒泡几种方式
dangerouslySetInnerHTML 使用场景与风险
React 为什么不直接操作 DOM
Fragment 作用，短语法 <>
React 严格模式 StrictMode 作用

三、类组件生命周期（Class Component）

类组件完整生命周期分哪三个阶段
constructor 执行时机与作用
static getDerivedStateFromProps 执行时机与用途
shouldComponentUpdate 返回值作用
render 执行规则，禁止在其中修改 state
componentDidMount 执行时机、常用场景
getSnapshotBeforeUpdate 触发时机、返回值用途
componentDidUpdate 参数含义，依赖判断写法
componentWillUnmount 清理资源场景
废弃生命周期函数有哪些，为什么废弃
props 变化触发的生命周期流程
setState 同步还是异步，底层批量更新逻辑
setState 两种传参形式（对象/函数）区别
多次连续 setState 合并规则
如何在 setState 后拿到最新 state

四、Hooks 全套（React16.8+）

Hook 诞生背景，解决类组件什么痛点
Hook 使用两条硬性规则
useState 底层原理，为何数组解构不受顺序影响
useState 传入函数初始化的优势
useEffect 作用，依赖数组含义
useEffect 模拟生命周期分别怎么写
useEffect 返回清理函数执行时机
依赖数组漏传变量引发的闭包陷阱
useLayoutEffect 和 useEffect 执行顺序、区别
useMemo 缓存计算值，解决什么问题
useCallback 缓存函数，搭配子组件使用场景
useMemo 与 useCallback 性能误区
useRef 存储DOM、存储可变数据两种用法
ref 传递 forwardRef 使用场景
useImperativeHandle 作用
useContext 跨层级传值，使用缺陷
useReducer 适用场景，和 useState 对比
useReducer 简单实现思路
useId 作用，解决什么问题
useTransition 区分紧急/非紧急更新
useDeferredValue 延迟计算值
useSyncExternalStore 订阅外部数据源
useDebugValue 自定义Hook调试展示
自定义 Hook 封装规范，复用逻辑思路
Hook 闭包陷阱完整成因与解决方案

五、React18 新特性

React18 并发渲染 Concurrent Mode 含义
自动批处理更新范围变化
createRoot 替换 legacy root 差异
Suspense 服务端/客户端用法
Transitions API 解决场景
自动插入批处理，异步回调内也合并更新
useTransition 与 useDeferredValue 区别
服务端组件 RSC 基础概念
StrictMode 双重渲染机制目的
批量更新边界，何时不会合并state更新

六、Diff 算法与渲染更新

React Diff 三大策略
同层比较，不跨层级对比原因
无key、index key、唯一key三种场景对比
节点删除、新增、移动判断逻辑
文本节点、组件节点 Diff 区别
列表 Diff 优化逻辑
什么情况下组件会重新渲染
如何避免不必要的重渲染
memo、useMemo、useCallback 配合使用完整逻辑
渲染流程：render → 生成VNode → Diff → 真实DOM更新

七、组件通信方案

父子组件 props 传值、回调传方法
多层级透传 props 缺点
Context API 跨层级通信优缺点
Context 配合 useReducer 简易状态管理
父访问子组件实例 ref
子调用父方法回调函数
兄弟组件通信几种方案
全局事件总线实现与缺陷
跨页面全局状态管理方案对比

八、状态管理 Redux / Redux Toolkit / Zustand

Redux 三大核心原则
Redux 五大核心概念：Store、Action、Reducer、Dispatch、State
Reducer 必须纯函数要求
Action plain object 规范，为什么不能异步
中间件 middleware 作用，执行流程
redux-thunk 异步处理原理
redux-saga 对比 thunk 优势
combineReducers 拆分模块原理
react-redux 核心 API Provider、connect
mapStateToProps、mapDispatchToProps 作用
useSelector、useDispatch Hook 用法
Redux 数据单向流动完整流程
Redux Toolkit 解决原生Redux哪些痛点
createSlice 内置 reducer、action 生成
RTK 内置immer 实现可变写法原理
RTK Query 接口缓存、请求管理
Zustand 轻量状态库对比Redux优势
状态持久化 redux-persist 流程
大型项目状态库选型思路
多组件共享全局状态最佳实践

九、React Router v6

v5 与 v6 核心改动差异
createBrowserRouter 路由配置方式
BrowserRouter、HashRouter、MemoryRouter 区别
Routes 替代 Switch 作用
Route element 传组件写法
useNavigate 替代 useHistory
路由传参 params、search、state 三种方式
useParams、useSearchParams 使用
嵌套路由 Outlet 占位原理
index 索引路由作用
Link、NavLink 区别
路由守卫鉴权封装方案
路由懒加载 + Suspense 配置
useLocation 获取路由信息
动态路由、路由拦截封装

十、表单处理

受控组件与非受控组件定义、区别
受控组件完整实现思路
非受控组件通过 ref 获取值场景
多表单项统一封装受控逻辑
第三方表单库 Formik / React Hook Form 对比
React Hook Form 非受控高性能原理
表单校验方案：原生、yup、zod
表单批量重置、回填数据处理

十一、样式方案

inline 内联样式优缺点
CSS Modules 样式隔离原理
styled-components CSS-in-JS 原理
emotion 与 styled-components 对比
tailwindcss 在React项目使用优势
动态样式几种实现方式
全局样式污染解决方案

十二、工程化构建

Create React App 底层 webpack 配置
Vite 构建React项目优势，esbuild预构建
vite.config.js 常用配置项
webpack 处理jsx、ts-loader流程
babel 转换 JSX、polyfill 原理
.env 环境变量区分开发/测试/生产
跨域代理 proxy 配置
路由懒加载分包代码分割
Tree-Shaking 生效条件
打包体积优化手段
第三方组件库按需引入配置
unplugin-auto-import 自动导入hooks

十三、网络请求封装

axios 请求拦截、响应拦截封装
全局 loading、统一错误处理
token 过期无感刷新实现逻辑
重复请求取消方案 CancelToken
请求并发处理
封装自定义请求Hook
SWR / React Query 数据请求缓存库原理
React Query 自动重请求、缓存失效策略

十四、性能优化专题

组件无效重渲染全部诱因
memo 缓存函数组件条件
useCallback 缓存函数使用场景
useMemo 缓存计算结果适用场景
列表渲染优化策略
虚拟列表 react-window / react-virtualized 原理
图片懒加载实现
路由懒加载分包优化首屏
大组件拆分、状态下沉优化
避免在render内创建函数/对象
React DevTools Profiler 排查卡顿
减少Context频繁更新范围
定时器、订阅事件组件卸载清理
打包体积压缩：gzip、剔除无用依赖
并发更新优化用户交互体验

十五、进阶底层原理

Fiber 架构解决旧架构什么问题
Fiber 节点结构、任务拆分机制
协调阶段、提交阶段分工
可中断、可恢复、可优先级调度原理
调和过程完整流程
批量更新实现机制
合成事件系统底层池化机制
React 事务机制
Portal 传送门实现原理，事件冒泡特点
ErrorBoundary 错误捕获范围，无法捕获哪些错误
React 服务端渲染 SSR 流程
Next.js 与 CRA 区别，SSR/SSG/ISR 概念
Hydrate 水合作用，水合不匹配成因
RSC React Server Components 运行机制
微前端中 React 应用隔离方案

十六、项目实战场景题

项目目录分层架构设计
状态管理选型理由
大型表单封装思路
页面按钮、接口权限控制实现
首屏加载缓慢优化方案
列表大量数据渲染卡顿解决
全局弹窗、消息提示封装
路由鉴权、未登录跳转逻辑
组件复用抽离自定义Hook规范
线上报错捕获监控方案
多环境变量、多渠道打包配置
防抖节流在搜索框场景实现
页面返回保留表单状态实现
重复提交接口拦截处理
React 项目迁移 TS 改造思路

Redis 相关面试题整理

Wed, 15 Jul 2026 00:46:10 +0800

你的项目的哪些场景使用了 redis

如果发生了缓存击穿、穿透、雪崩如何解决

redis 作为缓存， mysql的数据如何与redis进行同步？

先介绍业务，看看业务符合什么场景
一致性较高场景
- 双写一致
  - 读
  - 写 | 延迟双删
  - 分布式锁
    - 读多写少
      - 共享锁
      - 排它锁
允许延迟一致

介绍一下你的异步方案

允许延时一致的业务，采用异步通知
- MQ消息中间件
- Canal中间件
强一致性（Redisson读写锁）
- 共享锁
  - 阻塞写操作
- 排它锁
  - 阻塞读和写操作

Redis作为缓存，数据的持久化是怎么做的？

RDB
- save
- bgsave
AOF

RDB 的执行原理？

fork主进程得到子进程
子进程共享主进程的内存数据（复制页表）
copy-on-write

AOF 的执行原理

配置项
always
everysec
no
重写触发
bgrewriteaof

RDB 和 AOF 对比

持久化方式
数据完整性
文件大小
宕机恢复速度
数据恢复优先级
系统资源占用
使用场景

redis 的key过期了会立即删除吗

惰性删除
定期删除
- SLOW（10hz）
- FAST

Redis的过期策略：惰性删除+定期删除配合使用

Redis 数据淘汰策略

noeviction
volatile-ttl
allkeys-random
volatile-random
allkeys-lru
volatile-lru
allkeys-lfu
volatile-lfu

数据库有1000万数据，redis只能缓存20万，如何保证redis中的数据都是热点数据？

使用 allkeys-lru

Vue 相关面试题整理

Wed, 15 Jul 2026 00:46:10 +0800

从互联网整理而来

一、JS/TS 前置基础

var、let、const 区别
原型、原型链原理
闭包概念、使用场景、内存泄漏风险
同步异步、宏任务微任务执行顺序
Promise 三种状态、链式调用、静态方法
async/await 底层原理
数组常用遍历方法差异
深浅拷贝实现与区别
Object.defineProperty 与 Proxy 对比
Reflect 对象作用
箭头函数与普通函数区别
解构赋值、展开运算符
ES6 模块 import/export 与 CommonJS 区别
TypeScript 泛型、接口、类型推导
EventLoop 完整执行流程

二、Vue2 基础核心

Vue 双向绑定底层原理
Object.defineProperty 如何监听对象、数组变化
Vue2 数组重写了哪些方法，为什么不能监听下标修改
Dep、Watcher、Observer 三者关系
什么是响应式依赖收集、派发更新
数据劫持流程完整过程
computed 和 watch 区别
computed 缓存实现原理
methods、computed、watch 使用场景区分
Vue 生命周期全部钩子及执行时机
created、mounted、updated、destroyed 使用场景
父子组件生命周期执行顺序
v-if 和 v-show 底层区别与性能差异
v-for 绑定 key 的作用，key 不能用 index 的原因
v-if 和 v-for 同时使用的优先级与问题
v-model 底层语法糖实现
修饰符 .lazy .number .trim 原理
指令自定义实现，钩子函数有哪些
过滤器 filter 使用场景，Vue3 废弃原因
插值表达式、v-text、v-html 区别
Vue 模板编译流程
render 函数与 template 关系
VNode 虚拟 DOM 结构作用
Diff 算法执行流程
Vue2 Diff 同层比较、key 作用、头尾指针优化
patch 函数更新逻辑
nextTick 原理，微任务/宏任务降级策略
$nextTick 使用场景

三、Vue2 组件通信

父子组件 props 传递规则，单向数据流
props 类型校验、默认值、必填配置
$emit 子传父实现
.sync 修饰符作用，Vue3 移除原因
$parent、$children、$refs 获取组件/元素
provide / inject 使用场景与响应式缺陷
EventBus 事件总线实现、内存泄漏问题
Vuex 全局状态通信完整流程
$attrs、$listeners 跨层级透传
跨页面、多层级组件通信方案对比

四、Vuex 状态管理

Vuex 五大核心概念 state、getters、mutations、actions、modules
mutations 必须同步、actions 异步原因
commit 和 dispatch 区别
getters 缓存特性
modules 模块划分，命名空间 namespaced
辅助函数 mapState/mapGetters/mapMutations/mapActions 使用
Vuex 持久化存储方案
Vuex 严格模式 strict 作用
多个组件同时修改同一 state 数据流
Vuex 底层响应式原理

五、Vue Router 2/3

SPA 单页面路由实现原理
hash 模式与 history 模式底层区别
history 模式后端 nginx 配置问题
路由导航守卫分类：全局、路由独享、组件内
导航守卫执行完整顺序
$route 和 $router 区别
路由传参 params 和 query 差异
params 刷新丢失参数解决方案
动态路由匹配、路由嵌套
路由懒加载实现与分包
addRoutes、addRoute 动态添加路由
路由元信息 meta 使用场景
路由缓存 keep-alive 原理
include/exclude/max 参数作用
activated、deactivated 生命周期钩子
路由跳转 push、replace、go 区别
登录鉴权全局路由拦截实现

六、Vue2 进阶知识点

keep-alive 缓存组件底层逻辑
异步组件、组件懒加载
组件递归实现菜单、树形结构
$once、$off、$on 事件方法
插槽分类：默认插槽、具名插槽、作用域插槽
作用域插槽数据传递原理
v-once 指令作用
Vue 模板编译生成 AST 抽象语法树
异步更新队列机制
页面大量数据渲染卡顿优化方案
Object.freeze 冻结数据对响应式的影响
$set 原理，什么场景必须使用
Vue2 响应式存在的缺陷
全局过滤器、全局指令、全局组件注册
mixin 混入原理、合并规则、冲突问题

七、Vue3 核心升级（Composition API）

Vue3 相比 Vue2 性能提升点
Vue3 响应式改用 Proxy 优势
Proxy 对比 Object.defineProperty 解决了哪些痛点
Reflect 配合 Proxy 的作用
reactive、ref 区别与底层实现
ref 为什么基础类型需要包裹对象
toRef、toRefs 使用场景，解决的问题
computed 在 setup 中使用方式
watch、watchEffect 区别
watch 监听对象、数组深度监听配置
setup 执行时机，this 指向问题
setup 参数 props、context 内容
Composition API 对比 Options API 优势
script setup 语法糖带来的变化
script setup 中 defineProps、defineEmits、defineExpose
生命周期钩子组合式写法 onMounted/onUpdated 等
getCurrentInstance 获取组件实例
provide / inject 在 Vue3 中如何实现响应式
自定义 hooks 封装思路，复用逻辑
Vue3 生命周期完整列表，与 Vue2 对应关系

八、Vue3 模板、编译、Diff 优化

Vue3 模板编译优化：PatchFlags 标记
静态提升原理，减少 VNode 创建开销
缓存内联事件处理函数
Vue3 Diff 算法优化：最长递增子序列
Diff 对比流程相比 Vue2 改进点
Fragment 根节点多标签支持原理
Teleport 传送门组件底层实现
Suspense 异步组件加载处理
v-model 在 Vue3 语法变更，多 v-model 实现
.v-model 修饰符自定义处理
插槽 v-slot 简写语法变化
Vue3 移除 filter 过滤器替代方案

九、Pinia（Vue3 状态管理）

Pinia 相比 Vuex 的优势
Pinia 核心概念 state、getters、actions
Pinia 支持同步异步，不再区分 mutations
defineStore 定义仓库，id 作用
直接修改 state 与 $patch 批量更新区别
$reset、$subscribe、$onAction 使用场景
Pinia 模块化拆分，无需命名空间
Pinia 持久化插件使用
setup 语法下使用 Pinia
多个仓库互相调用数据方法

十、Vue Router 4（Vue3）

createRouter、createWebHashHistory、createWebHistory
RouterView、RouterLink v-slot 插槽用法
useRoute、useRouter 组合式 API 获取路由实例
动态路由 addRoute 替换 addRoutes
路由守卫组合式写法
路由缓存与 Suspense 配合
路由元类型 TS 类型提示处理

十一、Vue3 高级特性

watchPostEffect、watchSyncEffect 区别
shallowRef、shallowReactive 浅层响应式作用
readonly、shallowReadonly 只读代理
customRef 自定义响应式引用
effectScope 作用域收集副作用
defineCustomElement 构建原生 webComponent
Vue3 全局 API 变更 createApp 替代 new Vue()
app.config 全局配置项
全局组件、指令、插件注册方式变化
Transition、TransitionGroup 动画组件原理
v-memo 缓存 VNode 优化渲染
异步 setup 函数配合 Suspense

十二、工程化 & 构建工具

Vue CLI 与 Vite 底层构建区别
Vite 冷启动快的原理，esbuild 预构建
Vite 热更新 HMR 实现机制
vite.config.js 常用配置
webpack 打包 Vue 文件流程 vue-loader
.vue SFC 单文件组件解析过程
scoped 样式隔离原理，深度选择器 /deep/ ::v-deep :deep()
CSS Module 使用方式
环境变量 .env 文件区分开发测试生产
跨域代理 proxy 配置
打包体积优化方案
分包、懒加载、gzip 压缩配置
TS 在 Vue 项目中配置声明文件
第三方 UI 库按需引入配置
全局自动导入组件、API 插件 unplugin-auto-import

十三、网络请求与封装

axios 拦截器请求、响应封装思路
请求 loading、统一错误处理封装
token 过期自动刷新逻辑
请求取消、重复请求拦截方案
并发请求处理
接口数据统一格式化处理
封装请求 hooks 适配 Vue3

十四、性能优化专项

减少不必要组件渲染手段
v-once、v-memo 使用场景
长列表虚拟滚动实现原理
响应式数据避免不必要监听
computed 缓存减少重复计算
图片懒加载方案
路由懒加载分包优化
keep-alive 合理缓存减少重复请求
避免频繁触发 watch
大列表数据冻结 Object.freeze
减少 DOM 操作，合理使用虚拟 DOM
打包体积优化：Tree-Shaking、剔除无用依赖
Vite/Webpack 构建速度优化
内存泄漏常见场景：定时器、事件监听、未销毁订阅
Chrome Performance 面板排查页面卡顿

十五、混合、插件、拓展开发

Vue2 mixin 缺陷，Vue3 用 hooks 替代原因
Vue 插件开发完整结构 install 方法
全局自定义指令完整开发
封装业务通用组件规范
二次封装 Element Plus / Ant Design Vue
封装全局弹窗、消息提示组件
自定义全局权限指令 v-permission
页面权限、按钮权限实现方案
全局错误捕获 errorHandler
埋点、全局请求监控插件封装

十六、项目实战场景问答题

项目整体架构分层设计
Vue2 升级 Vue3 迁移改造遇到的问题
大型项目状态管理选型 Vuex / Pinia 理由
复杂树形菜单、表格组件封装思路
表单校验全局统一封装方案
页面权限控制完整实现流程
多环境配置、多渠道打包处理
首屏加载速度优化做了哪些处理
路由鉴权、未登录拦截逻辑
列表大量数据渲染卡顿如何解决
项目打包体积过大优化方案
页面缓存、返回保留表单状态实现
接口并发冲突、重复提交拦截
移动端适配方案 vw/vh、rem
线上报错监控、异常捕获方案

微信小程序相关面试题整理

Wed, 15 Jul 2026 00:46:10 +0800

从互联网整理而来

一、基础概念与运行机制

小程序与H5、App的核心区别
小程序双线程模型分别是什么，各自职责
逻辑层与视图层通信方式
小程序渲染流程完整过程
小程序启动流程（冷启动、热启动）
冷启动和热启动的差异
小程序分包加载机制概念
主包与分包限制规则
独立分包和普通分包区别
小程序的生命周期分类（应用、页面、组件）
小程序页面栈规则，最多存放多少页面
小程序登录流程整体逻辑
微信授权两种类型区别（基础授权、隐私授权）
小程序原生宿主环境提供哪些能力
小程序更新机制，静默更新与主动更新

二、文件结构与配置

小程序四种核心文件作用（json/wxml/wxss/js）
app.json 全局配置常用字段
page.json 页面配置优先级与app.json关系
sitemap.json 作用
project.config.json 用途
app.js 全局App实例生命周期
页面js Page构造器生命周期
组件js Component构造器生命周期
usingComponents 引入组件配置
全局样式app.wxss和页面wxss权重规则
wxss与css差异，特有特性
rpx单位换算规则，适配原理
小程序支持的选择器有哪些，不支持哪些
图片、静态资源本地与线上引入规则
分包配置subpackages字段参数含义

三、WXML 模板语法

WXML数据绑定语法规则
插值表达式支持哪些运算
wx:if、wx:elif、wx:else 条件渲染
hidden属性与wx:if性能差异
wx:for列表渲染，wx:key作用
wx:key使用规范，禁止index的场景
block标签作用，是否生成真实节点
模板template定义与引入，数据传递
wxs脚本作用，运行环境限制
wxs与js的区别，能否调用小程序API
事件绑定bind、catch、capture-bind区别
mut-bind互斥事件作用
事件传参几种实现方式
数据双向绑定model语法
标签属性布尔值绑定规则

四、组件系统（原生+自定义组件）

小程序自定义组件创建完整结构
Component中properties传参配置规则
properties三种数据监听方式
data、properties、observers执行顺序
observers监听对象、数组深层变化写法
组件生命周期完整钩子
lifetimes与pageLifetimes区别
组件插槽slot，具名插槽使用
组件父子通信方式
triggerEvent触发自定义事件传参
selectComponent、selectAllComponents获取子组件
behaviors复用逻辑，合并规则
原生内置常用容器、表单、媒体组件
scroll-view滚动注意事项
movable-area、movable-view实现拖拽原理
canvas新旧版本差异，2d画布使用
web-view嵌入H5通信方案
cover-view、cover-image使用限制场景
自定义组件样式隔离options配置
组件pureDataPattern作用

五、数据管理与渲染更新

setData底层更新原理
setData频繁调用性能问题
setData单次数据大小限制
局部更新数据简写写法
直接修改this.data不调用setData为什么不更新视图
复杂对象、数组更新setData写法
全局数据共享几种方案
getApp()全局变量优缺点
globalData跨页面同步更新缺陷
数据本地持久化storage存储限制
wx.setStorage同步异步API区别
storage大数据存储优化方案
页面间数据传递方式对比
页面栈取上一页实例方法
大数据列表渲染卡顿优化思路

六、路由与页面跳转

五种路由API区别（navigateTo/redirectTo/reLaunch/switchTab/navigateBack）
switchTab跳转限制条件
navigateTo无法跳tab页面解决方案
路由传参两种方式，长参数丢失问题
页面返回监听onUnload、onShow触发时机
获取当前页面栈方法getCurrentPages()
路由拦截统一封装思路
tabBar配置规则，自定义tabBar实现
自定义tabBar踩坑点
页面跳转后保留表单状态方案

七、网络请求与后端交互

wx.request请求基础配置
request合法域名校验规则，开发环境规避
小程序请求携带cookie机制
请求header统一封装token思路
拦截器封装wx.request方案
并发请求、请求超时处理
文件上传wx.uploadFile参数配置
文件下载wx.downloadFile使用场景
websocket实时通信完整流程
socket断线重连实现逻辑
接口返回加密数据解密处理
批量请求统一捕获异常
小程序不支持跨域的根本原因
上传图片压缩、裁剪处理
上传进度监听API

八、登录、授权、用户信息

wx.login获取code作用
code换取openid完整流程
openid、unionid区别与生成规则
隐私保护新规下获取用户头像昵称方案
getUserInfo接口废弃替代方案
手机号一键登录流程
授权scope各权限含义
用户拒绝授权后重新引导授权逻辑
登录态session_key过期处理
第三方登录、关联账号实现
登录状态持久化存储方案
多端打通unionid获取条件
隐私协议弹窗实现规范
小程序订阅消息下发流程
模板消息与订阅消息区别

九、媒体、图片、地图、设备API

wx.chooseMedia选择图片视频参数
图片预览wx.previewImage使用
图片本地缓存方案
录音、播放音频API使用
video视频播放常见问题
map地图组件标记、覆盖物绘制
获取当前定位wx.getLocation权限配置
后台持续定位配置要求
设备信息、系统API获取
振动、剪贴板、屏幕亮度API
扫码wx.scanCode场景
蓝牙BLE设备连接流程
NFC基础使用场景
相机camera组件适配
文件管理FileSystemManager读写文件

十、性能优化专项

setData性能优化手段
长列表渲染优化方案
虚拟列表实现思路
分包加载优化首屏速度
图片懒加载处理
减少页面、组件层级嵌套
wxss样式体积压缩优化
分包预加载preloadRule配置
避免频繁创建定时器、监听事件
页面卸载清除所有订阅、定时器
包体积超限优化方案
开发者工具性能面板排查卡顿
避免在onShow频繁请求接口
图片资源压缩、webp适配
减少observers深层监听开销

十一、适配、兼容、多端

rpx、px、rem转换关系
刘海屏、安全区适配css写法
深色模式适配配置
不同微信版本API兼容处理
caniuse判断接口是否可用
小程序转H5、转uni-app差异
平板、PC端小程序适配要点
低版本微信兼容降级方案
字体、图片多设备适配
自定义导航栏适配胶囊按钮

十二、工程化、第三方框架

原生小程序、uni-app、Taro区别
Taro编译原理，多端适配逻辑
uni-app分包、条件编译写法
小程序npm依赖使用规则
按需引入UI组件库优化
工程化打包、环境变量区分
多环境请求域名配置
ESLint校验小程序代码规范
Git协同开发规范
CI自动上传小程序工具

十三、支付、分享、广告、业务能力

小程序支付完整流程
支付回调后端处理逻辑
分享onShareAppMessage、onShareTimeline配置
分享图、分享路径动态处理
分享到朋友圈限制条件
插屏广告、激励视频广告接入
小程序跳转其他小程序API
跳转限制与关联配置要求
客服消息接入流程
商品卡片、搜索收录配置sitemap

十四、安全、审核、合规

小程序合法域名、业务域名、web-view域名区别
前端存储敏感信息安全风险
session_key不能传输到前端原因
接口数据防篡改简单方案
隐私合规要求有哪些
图片、内容审核API调用
小程序常见审核驳回原因
诱导分享、诱导支付违规点
本地存储数据加密思路
防止恶意刷接口方案

十五、实战场景综合题

项目整体目录架构设计
封装通用请求库完整思路
全局登录拦截、未登录跳转实现
大型表单组件封装与校验
多页面共享登录状态管理
列表上拉加载、下拉刷新封装
图片上传、预览、删除完整流程
分包改造解决主包体积超限
页面返回保留搜索条件、分页数据
小程序热更新主动检测逻辑
websocket聊天断线重连方案
自定义tabBar遇到的坑与解决
页面大量数据滑动卡顿优化
线上白屏、加载失败排查思路
原生小程序迁移Taro/uni改造方案

线性探测与链地址法的剖析

Sat, 11 Jul 2026 17:00:18 +0800

为什么我们需要两种冲突解决策略？

哈希表的核心矛盾在于：哈希函数将无限的定义域映射到有限的地址空间。根据鸽巢原理（Pigeonhole Principle），冲突是必然的。于是，计算机科学家们在"时间换空间“和”空间换时间“的永恒博弈中，诞生了两大流派：

开放定址法（Open Addressing）：所有元素都存储在数组本身，冲突时寻找其他空位——原地消化。
链地址法（Separate Chaining）：数组存储指针，冲突的元素在数组外形成链表——外部延展。

这两者看似只是实现细节的差异，实则反映了对内存模型、缓存行为、并发控制、最坏情况保证等底层哲学的不同理解。

一、线性探测（Linear Probing）：极简主义的得与失

1.1 算法精要

线性探测的规则极其简单：

插入: h(k), h(k)+1, h(k)+2, ... (mod m)
查找: 同插入序列，直到找到或遇到空位
删除: 标记为"墓碑"(DELETED)，不能物理清空

关键洞察：线性探测的查找路径是确定性的，这意味着它拥有完美的CPU缓存预取特性（Prefetching），在现代CPU架构下，连续内存访问的速度比指针跳转快一个数量级。

1.2 主聚集（Primary Clustering）的数学本质

这是线性探测最致命的缺陷，也是理解其性能天花板的钥匙。

假设负载因子为 α（α = n/m），当插入一个新元素时，它在某个位置发生冲突的概率不是简单的 α，而是该位置所在的连续占用块的长度占比。这个正反馈机制导致：

一旦形成长度为 L 的连续占用块，新元素落入该块的概率为 L/m
落入后，块长度变为 L+1，进一步增加未来冲突概率
最终导致占用块像雪崩一样快速增长

数学结论（Knuth 的经典分析）：

成功查找的平均探测次数 ≈ 0.5 * (1 + 1/(1-α))
插入的平均探测次数 ≈ 0.5 * (1 + 1/(1-α)^2)

当 α = 0.9 时，插入需要平均约 50.5 次探测，性能崩溃。这也是为什么线性探测要求负载因子严格控制在 0.7 以下。

1.3 删除与墓碑的隐藏代价

线性探测的删除必须使用墓碑，这带来三重悲剧：

空间污染：墓碑占用的位置无法被新数据直接覆盖（需要判断是否允许覆盖，复杂化逻辑）
查询退化：大量的墓碑会导致查找遍历过长的已删除序列
需要周期性重建（Rehash）：当墓碑比例超过阈值（如 30%），需要重新插入所有存活元素

// 墓碑导致的查找效率下降示意
[ A ] [ 墓碑 ] [ 墓碑 ] [ 墓碑 ] [ B ] [ 空 ]
// 查找 B：需要跳过 3 个墓碑，即使它们是空的，线性探测依然要检查

1.4 线性探测的"真香"场景

尽管有上述缺陷，线性探测在工业界依然被广泛使用，原因在于：

Docker Healthcheck 万金油

Sat, 11 Jul 2026 16:30:54 +0800

模板一：网络服务万金油（只要有网络端口，通杀）

如果容器是 Web 服务（如 Nginx、Tomcat、Node.js）、数据库（如 Redis、MySQL）或者各种中间件，只要它暴露了 TCP 端口，且容器内带有最基础的 sh，这就是最无敌的万金油配置。

它利用了 Linux 内核原生 </dev/tcp 漏洞，完全不依赖 curl 或 wget 。

healthcheck:
  # 语法解释：尝试与容器本地的 8080 端口建立 TCP 连接，失败则退出码为 1
  test: ["CMD-SHELL", "sh -c '</dev/tcp/127.0.0.1/8080' || exit 1"]
  interval: 10s # 10秒探一次，既保证敏锐度，又不会给系统带来TCP连接压力
  timeout: 3s # 握手超过3秒没反应，说明网络栈或主线程已经卡死
  retries: 3 # 连续失败3次（大约30秒内）正式宣判死刑
  start_period: 30s # 30秒新手保护期，给服务腾出启动和绑定端口的时间

注：使用时只需要把 8080 改成你容器内部的实际端口（如 Redis 改成 6379，Nacos 改成 8848）即可。

模板二：Java/Spring Boot 专属万金油（解决高 CPU 与 Full GC 假死）

对于 Java 应用，有时候端口虽然勉强能连上，但实际上 JVM 内部因为内存溢出（OOM）或者恐怖的 CPU 占用，已经完全无法处理业务了。

这时候用 Java 自带的诊断工具 jcmd 去拍 JVM 的脑袋，是最精准的万金油手段（前提是使用 JDK 镜像，非精简的 JRE）。

JAVA程序员防翻车指南

Thu, 09 Jul 2026 22:15:46 +0800

一、基础类型与字面量（1-10）

int 最大值 2,147,483,647（2³¹-1），最小值 -2,147,483,648（-2³¹）
long 最大值 9,223,372,036,854,775,807（2⁶³-1），字面量加 L
float 字面量必须加 f，否则默认 double
short 范围 -32,768 ~ 32,767，byte 范围 -128 ~ 127
字面量下划线：1_000_000 等于 1000000，仅 Java 7+
0x 开头是十六进制，0b 开头是二进制，0 开头是八进制（容易误判）
char 占 2 字节，Character.SIZE = 16，但 Unicode 扩展字符需 2 个 char（surrogate pair）
boolean 只有 true/false，不能和 0/1 互转（和 C 不同）
Integer.valueOf(127) == Integer.valueOf(127) 为 true，128 为 false（缓存池 -128~127）
Integer.parseInt("") 抛 NumberFormatException，Integer.parseInt(null) 也抛

二、运算符与表达式（11-18）

& 和 && 区别：& 两边都执行（位运算或逻辑与），&& 短路
| 和 || 同理，|| 短路
^ 按位异或，~ 按位取反（包含符号位）
>> 算术右移（补符号位），>>> 无符号右移（补 0）
i++ 和 ++i 的字节码区别：前者先加载后自增，后者先自增后加载
+= 隐式类型转换：short s = 1; s += 1; 合法，s = s + 1; 编译错误
三元运算符 ? : 必须返回相同类型，否则自动类型提升
字符串拼接用 + 在循环内会生成大量 StringBuilder，循环外编译器自动优化

三、String 相关（19-28）

String 不可变，底层 char[] 被 final 修饰且不暴露修改方法
字符串常量池在堆中（Java 8+），intern() 手动入池
new String("abc") 创建 2 个对象（常量池 + 堆），"abc" 只创建 1 个（若池中没有）
String.equals() 比较内容，== 比较引用地址
String.compareTo() 按字典序比较，返回差值
String.format() 使用 %s %d %f 占位符
substring() 在 Java 7 前共享 char[]，Java 7+ 创建新数组（解决内存泄漏）
split() 参数是正则，. 需转义为 \\.
replace() 替换所有字符，replaceAll() 支持正则
StringBuilder 线程不安全，StringBuffer 线程安全（方法加 synchronized），但慢

四、equals 与 hashCode（29-34）

重写 equals 必须重写 hashCode，否则 HashMap/HashSet 失效
equals 必须满足：自反、对称、传递、一致、非空（x.equals(null) 返回 false）
hashCode 相等的两个对象 equals 不一定相等（哈希冲突）
Objects.equals(a, b) 自动判空，避免 null.equals()
Arrays.deepEquals() 比较多维数组，Arrays.equals() 只比较一维
List.equals() 要求顺序相同，Set.equals() 仅要求元素相同（顺序无关）

五、异常处理（35-44）

try-catch-finally 中 finally 在 return 之前执行，但返回值已在 finally 前计算好
finally 中有 return 会覆盖 try/catch 的返回值
finally 中修改返回的引用对象内容会生效（如 List.add()）
不要在 finally 中写 return，也不要在其中抛出异常（会掩盖原始异常）
try-with-resources 要求资源实现 AutoCloseable，关闭顺序：先声明的后关闭
受检异常（Exception 子类）必须 try-catch 或 throws，RuntimeException 非受检
异常链：catch (SQLException e) { throw new RuntimeException(e); } 保留堆栈
printStackTrace() 不应用在生产日志中，用 log.error("msg", e)
Throwable 包括 Error 和 Exception，Error 不应该捕获（如 OutOfMemoryError）
finally 中关闭资源时可能抛异常，要用 try-catch 包裹或使用 try-with-resources

六、集合框架（45-62）

ArrayList 初始容量 10，扩容 1.5 倍（oldCapacity + (oldCapacity >> 1)）
ArrayList 随机访问 O(1)，中间插入删除 O(n)，LinkedList 相反
LinkedList 实现了 Deque，可作为队列/栈使用
HashMap 容量为 2 的幂，默认 16，负载因子 0.75，扩容 2 倍
HashMap 索引计算：(n - 1) & hash，hash = key.hashCode() ^ (h >>> 16)
Java 8+ HashMap 链表长度 > 8 且容量 >= 64 时转红黑树，< 6 时退化为链表
HashMap 的 key 为 null 时，hash 值为 0，存在 table[0]
ConcurrentHashMap 分段锁（Java 7）→ synchronized + CAS（Java 8+）
Hashtable 线程安全但全表锁，已淘汰
TreeMap 基于红黑树，有序（按 key 自然序或 Comparator）
LinkedHashMap 按插入顺序或访问顺序（accessOrder=true 可实现 LRU）
HashSet 底层是 HashMap，TreeSet 底层是 TreeMap
PriorityQueue 小顶堆，Comparator.reverseOrder() 可转大顶堆
ArrayDeque 优于 Stack（Stack 已废弃，ArrayDeque 线程不安全但更快）
Collections.synchronizedList() 包装为线程安全，但迭代时仍需手动同步
CopyOnWriteArrayList 读多写少场景，写时复制整个数组
List.of() / Set.of()（Java 9+）返回不可变集合，不能增删改
ArrayList.subList() 返回视图，对子列表操作会影响原列表，反之亦然

七、并发与线程（63-80）

创建线程的三种方式：Thread、Runnable、Callable（有返回值）
start() 启动线程，run() 只是普通方法调用
synchronized 可锁实例方法、静态方法（锁 Class）、代码块
wait() 释放锁，sleep() 不释放锁，yield() 让出 CPU 但不释放锁
wait()/notify() 必须在 synchronized 块中调用，否则抛 IllegalMonitorStateException
notify() 随机唤醒一个，notifyAll() 唤醒全部
死锁四条件：互斥、请求与保持、不可抢占、循环等待
破坏死锁：按固定顺序加锁、tryLock() 超时、使用 ReentrantLock
volatile 保证可见性和有序性（禁止指令重排），不保证原子性
AtomicInteger 用 CAS 实现原子操作，incrementAndGet() 底层是 Unsafe.compareAndSwapInt
ThreadLocal 用完后必须 remove()，否则线程池复用导致内存泄漏
ThreadLocal 底层是 ThreadLocalMap，key 是弱引用，value 是强引用
ExecutorService 用 shutdown() 优雅关闭，shutdownNow() 立即关闭
线程池核心参数：核心线程数、最大线程数、存活时间、阻塞队列、拒绝策略
四种拒绝策略：AbortPolicy（抛异常）、CallerRunsPolicy（调用者执行）、DiscardPolicy（丢弃）、DiscardOldestPolicy（丢弃最旧）
CachedThreadPool 最大线程数 Integer.MAX_VALUE，容易 OOM，慎用
FixedThreadPool 使用无界队列，任务积压可能导致 OOM
Future.get() 阻塞，CompletableFuture 异步回调更灵活

八、I/O 与 NIO（81-88）

File 只是路径抽象，不表示真实文件，exists() 判断是否存在
FileInputStream 读取字节，FileReader 读取字符（默认编码可能乱码）
BufferedReader 用 readLine() 按行读取，Files.readAllLines() 更简洁
InputStreamReader 可指定字符集：new InputStreamReader(new FileInputStream("a.txt"), StandardCharsets.UTF_8)
try-with-resources 自动关闭多个资源，用分号分隔
Path/Paths/Files（Java 7+）替代 File，Files.walk() 遍历目录树
NIO 核心：Channel + Buffer + Selector（多路复用）
ByteBuffer 读写切换需调用 flip()，clear() 清空，compact() 压缩

九、JVM 与内存（89-95）

JVM 内存区域：堆、栈、方法区（元空间）、程序计数器、本地方法栈
堆分代：年轻代（Eden + S0 + S1）→ 老年代，默认比例 8:1:1
OutOfMemoryError 常见原因：堆 OOM、元空间 OOM、直接内存 OOM、栈溢出
栈溢出 StackOverflowError，递归过深或无终止条件
System.gc() 仅建议 GC，不保证执行
finalize() 已废弃（Java 9+），对象自救不靠谱
类加载器：Bootstrap（rt.jar）→ Extension → Application，双亲委派模型

十、日期与时间（96-100）

java.util.Date 可变、线程不安全，已废弃，用 java.time.*（Java 8+）
LocalDate / LocalTime / LocalDateTime 不含时区，ZonedDateTime 含时区
Instant 时间戳（秒/纳秒），Duration 计算时间差，Period 计算日期差
格式化用 DateTimeFormatter 线程安全，替代 SimpleDateFormat（线程不安全）
LocalDateTime.now() 获取当前时间，parse("2026-07-09") 按 ISO 标准解析

十一、语法糖与常见坑（101-110）

泛型编译期擦除，运行时无泛型信息（List<String> 和 List<Integer> 在运行时相同）
可变参数本质是数组，public void method(String... args) 可传数组或逗号分隔
枚举 enum 默认继承 Enum，不能被继承，构造器私有
匿名内部类持有外部类引用（this$0），可能导致内存泄漏
接口默认方法 default，静态方法 static，接口中变量默认 public static final
抽象类可有构造器，接口无构造器
switch 支持 byte/short/char/int/String/enum，不支持 long/float/double
break 跳出循环，continue 跳过本次，return 结束方法
标签 label: 可跳出外层循环，但不推荐使用
数组协变：String[] 是 Object[] 的子类，但集合泛型不变

十二、网络与反射（111-118）

URL 和 URI 区别：URI 是标识符，URL 是定位符（包含协议）
HttpURLConnection 原生 HTTP 客户端，但 Apache HttpClient / OkHttp 更常用
Socket 阻塞 I/O，ServerSocket 监听端口，accept() 阻塞等待连接
反射 Class.forName() 初始化类，ClassLoader.loadClass() 不初始化
Method.invoke() 性能差，但反射能绕过私有访问（setAccessible(true)）
Proxy.newProxyInstance() 动态代理只能代理接口，CGLIB 可代理类
注解保留策略：SOURCE（源码）、CLASS（字节码）、RUNTIME（运行时）
序列化实现 Serializable 接口，serialVersionUID 用于版本兼容，不声明则自动生成

十三、设计原则与模式（119-123）

单例双重检查需 volatile，防止指令重排导致半初始化对象被读取
工厂模式解耦，策略模式消除 if-else，观察者模式事件驱动
依赖倒置：依赖抽象而非具体实现
开闭原则：对扩展开放，对修改封闭
里氏替换：子类可以替换父类出现的地方

十四、Linux 与常用命令（124-128）

nohup java -jar app.jar & 后台运行，输出到 nohup.out
jps 查看 Java 进程，jstack 打印线程堆栈，jmap 查看堆内存，jstat 监控 GC
kill -15 优雅关闭（SIGTERM），kill -9 强制杀死（SIGKILL）
tail -f app.log 实时查看日志，grep -C 10 "error" app.log 显示上下文
netstat -tlnp 查看端口占用，lsof -i:8080 查看指定端口

十五、数据库与 JDBC（129-133）

PreparedStatement 防 SQL 注入，占位符 ?，编译一次执行多次
Statement 拼接字符串有注入风险，不用
ResultSet 游标从 1 开始，next() 移动指针，getString(1) 按索引取
事务隔离级别：读未提交、读已提交、可重复读、串行化
连接池用 HikariCP（默认）、Druid，不要手动创建连接

十六、Maven / Gradle（134-137）

Maven 生命周期：clean → compile → test → package → install → deploy
provided 作用域表示运行时由容器提供（如 servlet-api）
依赖传递：compile 传递，test 不传递，provided 不传递
版本冲突用 dependencyManagement 锁定版本，或用 exclude 排除

十七、工具与调试（138-142）

System.out.println() 性能差，生产用日志框架（SLF4J + Logback）
日志级别：ERROR > WARN > INFO > DEBUG > TRACE
assert 默认禁用，需 -ea 开启，生产慎用
Objects.requireNonNull() 判空抛 NullPointerException，比手动 if 简洁
Optional 用来表示可能为 null 的返回值，不要用作字段或参数

十八、编码规范与常识（143-150）

包名全小写，类名大驼峰，方法/变量小驼峰，常量全大写 + 下划线
方法名用动词（getUser），变量名用名词（userName）
布尔变量用 is / has / can 开头（isDeleted）
一个 .java 文件只能有一个 public 类，文件名必须和 public 类名一致
构造器不能 static，不能被 final 修饰
static 块在类加载时执行一次，{} 实例块在构造器前执行
匿名对象（new User()）用完即抛，适合单次使用
永远不要在线上环境用 System.out 打印大对象，更不要用 e.printStackTrace()

漫谈AI上下文长度

Thu, 09 Jul 2026 20:58:34 +0800

flowchart TD
    A[2018–2021
512–2K Token
金鱼记忆时代] -->|只能处理短文、短句、单轮问答| B[2022–2023
4K–128K Token
中上下文普及时代]
    B -->|可处理论文、合同、小说、中型代码库
RAG 成为企业标准方案| C[2024–2025
200K–1M Token
百万上下文实验期]
    C -->|纸面支持 1M，但遗忘、成本、速度问题明显
仅限量 Beta| D[2026–2027
1M–2M Token
1M 量产普惠时代]
    D -->|1M 成为旗舰标配
可处理整卷宗、整代码库、全年业务日志| E[2028–2029
2M–10M Token
超百万窗口分化时代]
    E -->|2M 以上面向行业定制
长视频、大型代码库、多年日志联合分析| F[2030+
10M+ 弹性记忆
原生长记忆智能体时代]

一、大模型上下文完整进化时间线（2018–2026，分4个时代）

1. 初代Transformer时代：512–2K（2018–2021，金鱼记忆）

2018 GPT-1 / BERT：512 token，仅短文、短句分类，多轮对话必丢前文
2019 GPT-2：1024 token，能写短篇故事，连续对话3–5轮就遗忘历史
2020 GPT-3：2048 token（2K），行业通用标准，仅支持短提示词、少量示例，长文档必须分段/摘要处理
2021 早期国产（文心一言初代、GLM-1）：统一2K上限，无长文本能力

时代特征：没有原生长文本能力，所有长内容必须靠人工拆分、外部摘要，RAG雏形出现。

2. 中上下文普及时代：4K–128K（2022–2023，工业化可用）

2022 ChatGPT（GPT-3.5）：4K；年末升级16K，日常聊天够用，长文档仍吃力
2023.3 GPT-4 首发：8K，专业文档、代码单文件处理门槛打开
2023.7 Claude 2：100K，首个量产十万级窗口，法律、长篇论文场景爆发
2023.11 GPT-4 Turbo：128K，全球主流商用标配门槛，单本小说完整载入
2023年底国产跟进：通义、GLM、混元开放32K/64K；开源Llama 2、Qwen 7B固定4K–32K
2023.12 Gemini 1.0 Ultra 纸面宣称1M，但仅实验室封闭测试，无法商用落地

时代里程碑：128K成为专业AI标配；RAG成为行业标准方案，弥补窗口不足。

3. 百万上下文实验期：200K–2M纸面（2024–2025，纸面强、实际弱）

2024.2 Gemini 1.5 Pro：原生2M token，全球首个公开百万级模型，但存在严重「中间遗忘Lost in the Middle」，后半段文档召回暴跌，仅适合摘要，不适合精细推理，仅限开发者限量Beta
2024 Claude 3 Opus：200K，稳定可靠，法律行业主力，无严重遗忘问题
2025 上半年：各大厂商放出1M Beta（Claude Sonnet 4、Gemini 2.0），长上下文计费溢价极高、响应慢、显存开销巨大，企业少量试用，普通用户无法接触
2025 国产开源：Qwen、DeepSeek推出64K–128K底座，少量实验版支持256K

时代特征：1M只是技术噱头，标称≠有效；硬件成本、遗忘问题、价格三重门槛，无法大规模落地。

一个程序员应该知道的各种锁

Thu, 09 Jul 2026 11:15:34 +0800

1. 悲观锁 vs 乐观锁（心态问题）

悲观锁：觉得肯定有人抢厕所，进去就反锁门（加锁），用完再开。
→ Java里的 synchronized 和 ReentrantLock 都是这种。安全，但慢。
乐观锁：觉得没人抢，不锁门，但上厕所时盯着门把手（版本号/时间戳），如果发现被人动过（冲突），就重试。
→ Java里的 CAS（比较并交换） 就是这种，比如 AtomicInteger。快，但冲突多时会反复重试。

2. 公平锁 vs 非公平锁（排队问题）

公平锁：先来后到，乖乖排队。
→ new ReentrantLock(true)。公平，但效率低（大家都得排队）。
非公平锁：新来的可以插队，如果锁刚好释放，它就直接抢。
→ synchronized 和默认的 ReentrantLock 都是非公平。效率高，但可能导致某些线程饿死（一直抢不到）。

3. 可重入锁（同一个人的多次进入）

你进了厕所A，发现里面还有个小隔间B，你能直接进B，不用再掏钥匙。
→ synchronized 和 ReentrantLock 都支持。同一个线程可以多次获取同一把锁，防止自己把自己卡死。

4. 读写锁（分情况管理）

厕所分蹲位（写锁）和洗手池（读锁）。
- 多人同时洗手（读）没问题。
- 但有人蹲坑（写）时，别人既不能蹲也不能洗手（全阻塞）。
  → ReentrantReadWriteLock。适合读多写少的场景。

5. 共享锁 vs 排他锁（权限级别）

排他锁（写锁）：厕所门一锁，谁也别进。
共享锁（读锁）：可以多人同时看同一份文件（但不能改）。
→ 读写锁就是共享/排他的典型实现。

6. 偏向锁 → 轻量级锁 → 重量级锁（锁升级，JVM自动优化）

这是 synchronized 的底层升级过程（为了性能）：

偏向锁：厕所只认你一个人，你每次来都不用掏钥匙（无竞争）。
轻量级锁：偶尔有别人来，你们用“自旋”方式（原地转圈等）抢，不挂起线程（省资源）。
重量级锁：竞争激烈，排队挂起（操作系统介入，慢）。
→ 这是JVM自动做的，你不用管，但知道它存在即可。

7. 自旋锁（不睡觉，死等）

厕所被占，你不去排队睡觉，而是在门口原地转圈（循环检查），等它释放。
→ 适合持有锁时间很短的情况，避免线程挂起/唤醒的开销。Java里的 CAS 就是自旋思想。

8. 分段锁（分块管理）

一个大厕所分成多个小隔间，锁只锁其中一间，不影响其他间。
→ ConcurrentHashMap 早期就是用分段锁，提升并发度（现在改用CAS+细粒度锁了）。

一张图总结（按使用场景选）：

场景	推荐锁
简单同步，代码少	`synchronized`
需要可中断、超时、公平等灵活功能	`ReentrantLock`
读多写少（如缓存）	`ReentrantReadWriteLock`
计数器、自增等简单操作	`AtomicXXX`（乐观锁）
追求极致性能，竞争不激烈	偏向锁/轻量级锁（JVM自动）

Docker 常用配置

Thu, 09 Jul 2026 11:04:37 +0800

Kafka

Kafdrop

services:
  kafdrop:
    image: obsidiandynamics/kafdrop
    container_name: kafdrop
    ports:
      - "9000:9000"
    environment:
      KAFKA_BROKERCONNECT: "localhost:9092"
      SERVER_SERVLET_CONTEXTPATH: "/"
    restart: unless-stopped

KRaft 模式

services:
  kafka:
    image: apache/kafka:3.9.0
    container_name: kafka
    hostname: kafka

    ports:
      - "9092:9092"

    environment:
      KAFKA_NODE_ID: 1

      KAFKA_PROCESS_ROLES: broker,controller

      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093

      # 注意：这里不要换行，不要逗号
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093

      # 外部访问地址
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092

      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT

      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER

      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT

      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1

      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1

      CLUSTER_ID: MkU3OEVBNTcwNTJENDM2Qk

    volumes:
      - ./data:/var/lib/kafka/data

    restart: unless-stopped

Java GC 是如何驱赶“老年群体”的

Thu, 09 Jul 2026 10:19:20 +0800

在 Java 的世界里，“分代年龄”（Age） 是专门为 JVM 垃圾回收（GC）设计的一个计数器。

简单来说，它记录了一个 Java 对象在垃圾回收中活过了多少轮。就像打游戏刷副本一样，对象每在垃圾回收的“清洗”中幸存下来一次，它的分代年龄就会 +1。

1. 为什么需要“分代年龄”？

这源于 Java 垃圾回收领域著名的 弱分代假说（Weak Generational Hypothesis）：

绝大多数的 Java 对象都是“朝生夕死”的。 比如你在一个方法里 new 了一个局部变量，方法结束了，这个对象就没用了。但也有极少数对象（如 Spring 的 Bean、数据库连接池）会一直存活。

为了高效管理内存，JVM 把堆内存分成了两大区域：

新生代（Young Generation）： 存放刚出生、寿命短的对象。
老年代（Old Generation）： 存放寿命长、常驻内存的对象。

“分代年龄”就是对象从“新生代”晋升到“老年代”的资格证和进度条。

2. 它的工作流程是怎样的？

我们可以把新生代想象成一个“新手村”，老年代想象成“满级主城”：

出生（0岁）： 绝大多数新对象在新生代的 Eden（伊甸园）区 出生。
第一次渡劫（1岁）： 发生了一次 Minor GC（新生代垃圾回收）。如果这个对象没被回收，它会幸存下来，被移动到 Survivor（幸存者）区，同时它的分代年龄变成 1 岁。
继续熬资历（每活过一轮 +1岁）： 以后每发生一次 Minor GC，只要它还在幸存者区折腾且没死掉，它的年龄就会加 1 岁。
晋升老年代： 当它的年龄达到一定阈值（默认是 15 岁，由 JVM 参数 -XX:MaxTenuringThreshold 决定）时，JVM 就会认为：“这小伙子挺能活，应该是个核心常驻对象。” 于是把它晋升（Promote）到老年代。

3. 它存在对象的什么地方？

正如我们在讨论“锁”时提到的，分代年龄存在于每个 Java 对象的 对象头（Object Header）的 Mark Word 里面。

为什么每个java对象都有锁的属性？这样不是浪费内存吗

Thu, 09 Jul 2026 10:11:43 +0800

1. 为什么当初要这样设计？（设计初衷）

Java 诞生于 20 世纪 90 年代中期，当时多线程编程（并发）正在兴起。Java 的设计者高斯林（James Gosling）希望 Java 成为一门简单易用的多线程语言。

简化并发编程

如果对象没有内置锁，你每次想给一段代码加锁，都必须显式地创建一个 Lock 对象：

// 如果没有内置锁，你得这么写：
Lock myLock = new ReentrantLock();
void doSomething() {
    myLock.lock();
    try {
        // 业务逻辑
    } finally {
        myLock.unlock();
    }
}

而 Java 设计者引入了 synchronized 关键字，直接让对象充当锁，把复杂的同步简化成了：

// 极简的同步写法
synchronized(this) {
    // 业务逻辑
}

“万物皆对象，万物皆可为锁”的设计，让开发者不需要管理一堆乱七八糟的锁对象，只要拿到目标对象，就能直接进行同步控制。

2. 这样不浪费内存吗？JVM 是怎么“偷懒”的？

你担心的内存浪费，JVM 工程师早就想到了。他们绝对不会傻到给每个刚 new 出来的对象都分配一个沉重的操作系统级别的锁（Monitor）。

JVM 解决这个问题的核心思路是：按需分配，动态升级。

秘密武器：对象头（Object Header）

在 Java 中，每个对象的内存结构里都有一个叫 Mark Word（标记字） 的区域（在 64 位虚拟机上占 8 个字节 / 64 位）。

H mod C = H & (C - 1) ?

Wed, 08 Jul 2026 17:38:40 +0800

在 Java 后端开发面试或源码阅读中，HashMap 永远是避不开的核心。很多人能熟练地背出它的扩容阈值、红黑树化条件，但当深入到源码底层，看到诸如 e.hash & (newCap - 1) 和 e.hash & oldCap 这样的位运算时，往往会陷入沉思。

一、起源：为什么数组长度必须是 2 的次幂？

在散列表中，为了让数据均匀分布，最直观的想法是对哈希值进行取模（求余数）：

$$\text{索引位置} = \text{hash} \pmod{\text{Capacity}}$$

然而，在 CPU 的底层底层执行中，除法和取模（%）是非常昂贵的算术操作（可能需要几十个时钟周期）。为了追求极致的性能，底层的数论定理为我们提供了一个完美的替代方案：

数学定理：当容量 $C$ 是 $2$ 的次幂（$2^n$）时，对于任意整数 $H$，满足：
$$H \pmod C \equiv H \ \& \ (C - 1)$$

位运算（&）在 CPU 中只需要 1 个时钟周期！为了享受到这个性能红利，HashMap 在源码中将容量死死限制为 2 的次幂：

// 默认初始容量 16 (2的4次方)
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4;

裁剪器的魔术：`hash & (newCap - 1)`

以容量 16 为例，16 - 1 = 15（二进制：0000 1111）。任何 Hash 值与 15 进行 & 运算，高位都会被无情“抹零”，只有最后 4 位被保留下来：

限流降级研究笔记

Tue, 07 Jul 2026 16:05:10 +0800

主流算法

固定窗口计数器

每秒一个计数器，+1超过阈值就拒绝

缺点 0.51s 和 1.51s 之间产生2倍流量

滑动窗口

把时间切成更细的小格，滑动统计

缺点解决临界问题，但是实现复杂

漏桶

请求进桶，匀速流出，桶满则弃

缺点流出速度恒定，扛不了正常的突发

令牌桶

匀速往桶里放令牌，来请求拿令牌，没令牌被拒绝

缺点允许一定突发

Java 从Random理解 CAS自旋模式

Sat, 06 Jun 2026 21:40:20 +0800

你理解这段代码吗？

do {
    oldseed = seed.get();
    newseed = (oldseed * ...) & mask;
} while (!seed.compareAndSet(oldseed, newseed));   // ← CAS

第〇层：先搞懂"变量"在多线程里的危险

假设有一个变量 seed = 100，两个线程同时想改它：

线程A：读到 seed=100 → 算出新值 200 → 写回 seed=200
线程B：读到 seed=100 → 算出新值 300 → 写回 seed=300

问题来了——两个人都读到了 100，各算各的，最后谁写得晚谁赢。A 的结果被 B 覆盖了，A 白干了，而且程序根本不知道出错了。

这就是经典的 线程安全问题。

第一层：解决办法有两条路

路线一：悲观锁（synchronized）
  → "我先把门锁上，别人别进来"
  → 安全但慢（别人要排队）

路线二：乐观锁（CAS）
  → "门不锁，但我写之前验一下，被人改了我就重来"
  → 快但可能要重试

你这段代码走的就是 路线二。

第二层：什么是 CAS？

CAS = Compare And Set（比较并设置），三个参数：

CAS(内存地址, 我期望的旧值, 我想写入的新值)

它做的事用大白话说：

“我记得这个值是 42，如果现在还是 42，就帮我改成 77。如果不是 42 了，说明有人动过了，啥也别干，告诉我失败了。”

常见缓存策略精析

Tue, 05 May 2026 22:46:44 +0800

缓存三兄弟

缓存穿透

是什么：大量请求查询数据库不存在的数据。缓存没有，持续击打数据库防范方法：

缓存空值
1. 数据库查不到也往缓存放一个空标记（TTL短，2分钟，该TTL过期了才能进行再次数据库查询）
2. 下一次同样的id来了直接被挡住
3. 优点：有效拦截大量穿透请求
4. 缺点：
  1. 恶意攻击造成大量不同的不存在的key，缓存堆满无效数据，浪费内存
  2. 延迟了数据一致性，新数据必须等缓存过期
布隆过滤器（推荐）
1. 启动时把所有合法id放入布隆过滤器；
2. 布隆过滤器不给进就真的没有；
3. 优点：
  1. 没有高内存占用风险
  2. 没有数据一致性风险
4. 缺点：
  1. 有极小误判率
  2. 增删要维护。数据更新时，要同步更新布隆过滤器
接口层限流和校验
1. API网关或Controller层做拦截
2. 参数校验、限流降级
互斥锁重建
1. 互斥锁主要解决缓存击穿（热点key过期），但是在缓存空对象场景下，如果有大量并发请求一个不存在的key，可以使用锁
2. 每次访问让一个线程去查DB，其他线程等待

大厂的实践

网关层校验参数格式，IP限流（挡掉脚本攻击）
过滤器层布隆过滤器
缓存层

缓存击穿

是什么：某个被疯狂访问的热点key，因为TTL一到，失效的一瞬间海量并发请求同时miss，同时到DB重建同一个key

防范方法：

互斥锁
1. 只让第1个miss的线程去查DB
2. 其他线程等一下再读缓存
  1. 高一致性：线程傻傻等待
  2. 低一致性：先给旧数据，下一次来查就是新的
逻辑过期
1. key永不物理过期，把过期时间存在value里面
2. 如果发现逻辑上过期了，异步开个线程重建
3. 当前请求先返回旧值

互斥锁的实现

如何搭建出正确的锁？

v1：SETNX key 1 抢锁，DEL key 释放

SETNX=“不存在才设置成功”，天然互斥。但问题：抢到锁的线程崩了、DEL 没执行 → 锁永远不释放 → 死锁。

v2：给锁加过期间

崩了也能自动过期。但关键：必须用一条原子命令 SET key value NX EX 30。

陷阱：别写成 SETNX + 再 EXPIRE 两条——如果刚 SETNX 成功、还没 EXPIRE 就崩了，又变回 v1 的死锁。“抢锁"和"设过期"必须一步做完。

构建一个聊天室需要的基础知识

Fri, 03 Apr 2026 11:45:26 +0800

基础知识

TCP 三次握手

客户端 - 服务器

三次握手目的：客户端的收发没问题，服务器的收发也没问题。

第一次握手：客户端发 SYN（同步请求）

客户端：我啥也不知道，我发个 SYN 消息出去，看看有没有人接收到。
如果没人回复，我再发几次（超时重传）。
这个时刻，客户端知道的事实是：
- 我发出去了，但不知道有没有人收到 ❌
- 我能不能收消息？不知道 ❌
- 对方存不存在？不知道 ❌

第二次握手：服务器回 SYN+ACK（同步+确认）

服务器收到了客户端的 SYN。
服务器回复 SYN+ACK：“我收到你的消息了，我也发一条试试，看看你能不能收到。”
这个时刻，服务器知道的事实是：
- 客户端发消息是没有问题的 ✅（因为我收到了）
- 服务器收消息是没有问题的 ✅（因为我收到了）
- 服务器不知道服务器发消息有没有问题 ❌（我发出去了，但不知道对方收到没）
- 服务器不知道客户端收消息有没有问题 ❌（我发出去了，但不知道对方收到没）
- 服务器需要发送一条 SYN+ACK，等对方回复 ACK 来确认“我能发、对方能收”
当客户端收到 SYN+ACK 后，客户端可以确定以下事实：
- 我发消息是没有问题的 ✅（我发的 SYN 被收到了）
- 我收消息也是没有问题的 ✅（我收到了对方的回复）
- 服务器收消息是没有问题的 ✅（对方收到了我的 SYN）
- 服务器发消息也是没有问题的 ✅（我收到了对方的 SYN+ACK）
- ✅ 客户端这边已经确认全双工通信没问题了！
- 但是服务器他还有顾虑（不知道自己能不能发、不知道我能不能收），我再发个 ACK 给他吧

第三次握手：客户端发 ACK（确认）

客户端收到 SYN+ACK 后，回复一个 ACK：“我收到你的 SYN+ACK 了，我这边收发都没问题，你也可以放心了。”
当服务器收到这个 ACK 后，服务器可以确定以下事实：

为什么有时候后端需要维护一张Refresh_Tokens表

Mon, 02 Mar 2026 20:07:07 +0800

正常 JWT 请求流程

sequenceDiagram
    participant User as 用户
    participant Frontend as 前端（浏览器/App）
    participant Auth as 认证服务器
    participant Backend as 后端API服务器

    Note over User,Backend: 1. 登录阶段
    User->>Frontend: 输入用户名/密码
    Frontend->>Auth: POST /login (凭证)
    Auth->>Auth: 验证凭证
    Auth-->>Frontend: 返回 access_token + refresh_token
    Frontend->>Frontend: 存储token（内存/localStorage）
    Frontend-->>User: 登录成功

    Note over User,Backend: 2. 正常请求阶段
    User->>Frontend: 请求受保护资源
    Frontend->>Backend: GET /api/resource
Authorization: Bearer access_token
    Backend->>Backend: 验证access_token签名和过期时间
    Backend-->>Frontend: 返回请求的资源
    Frontend-->>User: 展示数据

    Note over User,Backend: 3. Access Token过期
    User->>Frontend: 继续请求
    Frontend->>Backend: GET /api/resource
Authorization: Bearer access_token(已过期)
    Backend-->>Frontend: 401 Unauthorized (token过期)
    Frontend->>Frontend: 检测到401，触发刷新逻辑

    Note over Frontend,Auth: 4. 刷新Token阶段
    Frontend->>Auth: POST /refresh
refresh_token
    Auth->>Auth: 验证refresh_token
    Auth-->>Frontend: 返回新的 access_token（可选的新refresh_token）
    Frontend->>Frontend: 更新存储的access_token
    Frontend->>Backend: 重试原请求（新access_token）
    Backend-->>Frontend: 返回请求的资源
    Frontend-->>User: 展示数据

为什么不能只靠JWT

refresh token 发出去后后端不保存，会变成 不可控的长期通行证
无法主动踢人下线
无法注销单点设备
无法判断 token 是否被盗用（攻击者拿到了 refresh token 可以一直刷新 access token）
无法实现会话管理

使用 refresh tokens 表后的流程图

sequenceDiagram
    participant User as 用户
    participant Frontend as 前端
    participant Auth as 认证服务器
    participant DB as 数据库(refresh_tokens表)
    participant Backend as 后端API服务器

    Note over User,DB: 1. 登录阶段（签发token + 入库）
    User->>Frontend: 输入用户名/密码
    Frontend->>Auth: POST /login
    Auth->>Auth: 验证凭证
    Auth->>DB: 生成唯一refresh_token_id
INSERT INTO refresh_tokens
(user_id, token_hash, expires_at,
 device_info, ip_address, revoked)
    DB-->>Auth: 插入成功
    Auth->>Auth: 生成access_token + refresh_token
(refresh_token包含id引用)
    Auth-->>Frontend: 返回access_token + refresh_token
    Frontend->>Frontend: 存储token
    Frontend-->>User: 登录成功

    Note over User,Backend: 2. 正常请求（与之前相同）
    User->>Frontend: 请求资源
    Frontend->>Backend: GET /api/resource
Authorization: Bearer access_token
    Backend->>Backend: 验证access_token
    Backend-->>Frontend: 返回资源

    Note over Frontend,DB: 3. Access Token过期 → 刷新
    Frontend->>Backend: GET /api/resource (access_token过期)
    Backend-->>Frontend: 401 Unauthorized
    Frontend->>Auth: POST /refresh
refresh_token

    Note over Auth,DB: 4. 刷新验证（多步校验）
    Auth->>Auth: 解析refresh_token，提取token_id
    Auth->>DB: SELECT * FROM refresh_tokens
WHERE id = token_id
    DB-->>Auth: 返回记录
    
    Auth->>Auth: 校验清单：
    Note over Auth: ✅ token_hash是否匹配
✅ 是否过期 (expires_at > now())
✅ 是否被撤销 (revoked = false)
✅ 用户是否仍有效
✅ 设备信息是否一致（可选）
    
    alt 校验全部通过
        Auth->>DB: UPDATE refresh_tokens
SET last_used_at = now(),
    last_used_ip = current_ip
WHERE id = token_id
        Auth->>Auth: 生成新access_token
（可选：延长refresh_token有效期）
        Auth-->>Frontend: 返回新access_token
        Frontend->>Frontend: 更新access_token
        Frontend->>Backend: 重试原请求（新token）
        Backend-->>Frontend: 返回资源
    else 校验失败
        Auth-->>Frontend: 401/403 (刷新失败)
        Frontend->>Frontend: 清除所有token
        Frontend->>User: 跳转登录页
    end

    Note over User,DB: 5. 主动登出
    User->>Frontend: 点击登出
    Frontend->>Auth: POST /logout
refresh_token
    Auth->>DB: UPDATE refresh_tokens
SET revoked = true
WHERE id = token_id
    Auth-->>Frontend: 登出成功
    Frontend->>Frontend: 清除本地token
    Frontend-->>User: 已登出

    Note over User,DB: 6. 安全场景：密码修改
    User->>Frontend: 修改密码
    Frontend->>Auth: POST /change-password
    Auth->>DB: UPDATE refresh_tokens
SET revoked = true
WHERE user_id = current_user_id
    Note over DB: 撤销该用户所有refresh_token
（强制所有设备重新登录）
    Auth-->>Frontend: 密码修改成功
    Frontend->>Frontend: 清除本地token
    Frontend-->>User: 请重新登录

微服务认证系统的架构梳理和面试应对

Mon, 26 Jan 2026 18:05:16 +0800

技术栈：Spring Boot 3 · Spring Cloud Alibaba · OpenFeign · JWT · Gateway · Nacos

如何使用这份文档

面试讲项目，最忌讳从代码细节讲起。正确顺序是：

先讲它解决什么问题 → 再讲整体架构 → 然后按请求流程串一遍 → 最后应对深挖。

本文档按这个顺序组织。带 🎤 标记的引用框，是可以基本照着说的话术。

一、一句话概述（开场用）

🎤 我做了一套基于 Spring Cloud Alibaba 的微服务认证系统。它把「认证」这件事拆成三个角色：auth 服务负责签发令牌、网关负责统一校验令牌、各业务服务通过请求头拿到用户身份。整体用 JWT 做无状态认证，服务之间用 OpenFeign 通信，靠 Nacos 做服务发现。

关键词锚点（面试官会顺着这些追问，要准备好）：无状态 JWT、网关统一鉴权、OpenFeign 远程调用、Nacos 服务发现、BCrypt 密码加密、职责分离。

二、它解决什么问题（讲动机）

背景：系统是微服务架构，有多个独立服务（auth、user-service、archive-service 等）。如果每个服务各自做一遍登录校验，会有两个问题：

重复：每个服务都写一遍鉴权逻辑，改规则要改很多处。
有状态难扩展：传统 session 存在单台服务器内存里，多实例之间不共享，扩容困难。

解决思路：「网关统一安检 + JWT 无状态令牌」。所有请求先经过网关校验令牌，业务服务不再重复鉴权；令牌本身自包含用户信息，验证只需用密钥本地验签，不依赖服务端存储。

🎤 类比机场：网关是安检口，严格查一次护照（验签）；过了安检给你贴个写着身份的手环（请求头里的用户 id）；后面登机口、免税店（各业务服务）只看手环，不再查护照。验签只做一次，业务服务零负担。

三、整体架构（讲骨架）

模块划分：项目是 Maven 多模块微服务，核心模块及职责如下。

模块	类型	职责
gateway	网关	所有请求入口；统一校验 JWT；按路由转发到后端服务
auth	认证服务	登录、注册；验密码；签发 JWT。自己不连数据库
user-service	业务服务	管理用户数据（tb_user 表的增删改查）
archive-service	业务服务	档案业务；从请求头读取当前用户身份
api	契约模块	存放各服务的 Feign 接口声明 + 配套 DTO（被各服务依赖）
common	基建底座	统一返回 Result、全局配置、ThreadLocal 用户上下文等

一个关键设计——auth 与 user-service 分离：auth 只管「认证动作」（验密码、发令牌），不碰数据库；它要用户数据时，通过 OpenFeign 远程调用 user-service 去查。user-service 只管「用户数据」，不掺和登录逻辑。

说一说登录这件麻烦事

Fri, 26 Dec 2025 15:56:40 +0800

从手机验证码到 Passkey，聊聊登录背后那些没人愿意细想的麻烦，以及一套可落地的最佳实践。

Spring Boot 常用代码片段

Wed, 26 Nov 2025 09:51:37 +0800

通用

依赖管理

父 pom.xml 固定三版本管控

版本参考

<dependencyManagement>
    <dependencies>
        <!-- 1. SpringBoot 基础版本 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>3.5.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

        <!-- 2. Spring Cloud 云原生基础 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2025.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

        <!-- 3. Spring Cloud Alibaba 阿里全套依赖核心（关键！） -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2025.0.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

启动类

@MapperScan("asia.liminality.user.mapper")
@SpringBootApplication
@Slf4j
public class UserApplication {
    public static void main(String[] args) throws UnknownHostException {
        ConfigurableApplicationContext app = SpringApplication.run(UserApplication.class, args);
        Environment env = app.getEnvironment();
        String protocol = "http";
        if (env.getProperty("server.ssl.key-store") != null) {
            protocol = "https";
        }
        log.info("--/\n---------------------------------------------------------------------------------------\n\t" +
                        "Application '{}' is running! Access URLs:\n\t" +
                        "Local: \t\t{}://localhost:{}\n\t" +
                        "External: \t{}://{}:{}\n\t" +
                        "Profile(s): \t{}" +
                        "\n---------------------------------------------------------------------------------------",
                env.getProperty("spring.application.name"),
                protocol,
                env.getProperty("server.port"),
                protocol,
                InetAddress.getLocalHost().getHostAddress(),
                env.getProperty("server.port"),
                env.getActiveProfiles());

    }
}

domain

DTO

Result

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Result<T> {

    private int code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        return new Result<>(200, "success", data);
    }

    public static <T> Result<T> success() {
        return new Result<>(200, "success", null);
    }

    public static <T> Result<T> failure(String message) {
        return new Result<>(500, message, null);
    }

    public static <T> Result<T> failure(int code, String message) {
        return new Result<>(code, message, null);
    }

    public static <T> Result<T> failure(String message, T data) {
        return new Result<>(500, message, data);
    }
}

Spring Cloud Gateway

AuthGlobalFilter

@Slf4j
@RequiredArgsConstructor
@Component
public class AuthGlobalFilter implements GlobalFilter, Ordered {

    private final JwtUtil jwtUtil;

    private static final List<String> WHITE_LIST = List.of(
            "/auth/user/login",
            "/auth/user/register"
    );

    // 判断是否在白名单内
    private boolean isWhiteList(String path){
        return WHITE_LIST.stream().anyMatch(path::startsWith);
    }

    private Mono<Void> reject(ServerWebExchange exchange){
        exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
        return exchange.getResponse().setComplete();
    }

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {

        ServerHttpRequest request = exchange.getRequest();

        String path = request.getPath().toString();

        if (isWhiteList(path)) {
            return chain.filter(exchange);
        }

        String token = request.getHeaders().getFirst("Authorization");

        // 令牌为空，拒绝访问
        if( token == null || token.isEmpty() ){
            return reject( exchange );
        }

        // 验证令牌
        try {
            Integer userId = jwtUtil.parseToken(token);
            // TODO userId 塞入请求头
            log.info("🚪 塞入请求头");
        } catch (Exception e) {
            return reject(exchange);
        }

        return chain.filter( exchange );
    }

    // 过滤器优先级，越小越靠前
    @Override
    public int getOrder() {
        return -1;
    }
}

PostgreSQL和java的LocalDateTime不兼容的问题

Sat, 25 Oct 2025 12:55:49 +0800

Java 的 LocalDateTime 和 PostgreSQL 的时间类型，“说的不是同一种时间”。

先搞清楚 PostgreSQL 的两种时间类型

TIMESTAMP           → 不带时区，就是个裸时间 "2026-06-25 10:00:00"
TIMESTAMPTZ         → 带时区，内部存 UTC，查询时按会话时区转换

Java 这边

LocalDateTime       → 没有时区概念，就是个裸时间
ZonedDateTime       → 带时区
OffsetDateTime      → 带偏移量（如 +08:00）
Instant             → UTC 时间戳

为什么会报错

PostgreSQL JDBC 驱动（特别是新版本 42.x+）对类型匹配非常严格：

flowchart TD
    A[Java LocalDateTime] --> B[JDBC驱动]
    B --> C{PostgreSQL列类型}
    C -->|TIMESTAMP| D[✅ 可以匹配]
    C -->|TIMESTAMPTZ| E[❌ 类型不匹配报错]

你的列如果是 TIMESTAMPTZ（带时区），但 Java 传的是 LocalDateTime（无时区），驱动不知道该用哪个时区换算，就直接拒绝了。

常见的三种报错

Cannot convert LocalDateTime to TIMESTAMPTZ
Bad value for type timestamp/date
column is of type timestamp with time zone but expression is of type timestamp

解决方案

方案一：改 Java 类型（推荐）

Swagger2和Swagger3注解对比表

Thu, 25 Sep 2025 09:06:35 +0800

在 Spring Boot 生态中，Swagger 2.0（通常使用 Foxfire 依赖）和 Swagger 3.0（通常使用 Springdoc-openapi 依赖，基于 OpenAPI 3 规范）的注解发生了很大变化。

以下是 Swagger 2.0 与 Swagger 3.0（OpenAPI 3）的常用注释完整对应表：

1. 核心注解对应表

功能描述	Swagger 2.0 注解 (io.swagger.annotations)	Swagger 3.0 注解 (io.swagger.v3.oas.annotations)	备注说明
标记控制器类	`@Api(tags = "用户接口")`	`@Tag(name = "用户接口")`	3.0 中移除了 `description` 属性，统一使用 `name`
标记接口方法	`@ApiOperation(value = "获取用户")`	`@Operation(summary = "获取用户")`	3.0 中 `value` 变更为 `summary`
入参实体类	`@ApiModel(value = "用户对象")`	`@Schema(description = "用户对象")`	3.0 极大简化，统一使用 `@Schema`
实体类属性	`@ApiModelProperty(value = "姓名")`	`@Schema(description = "姓名")`	同上，合并为了 `@Schema`
忽略某个属性	`@ApiModelProperty(hidden = true)`	`@Schema(hidden = true)`
忽略整个类/方法	`@ApiIgnore`	`@Hidden`	用于不想暴露在文档中的接口或参数

2. 请求参数注解对应表

对于方法入参（如 URL 路径参数、Query 参数等），3.0 引入了更具结构化的配置：

程序员快速参考小手册

Sun, 24 Aug 2025 22:51:14 +0800

有的命令一个月可能就用那么几次，不写手册里谁能记得住啊

VSCode

解决 code-runner Java Output 乱码

  "code-runner.executorMap": {
    "javascript": "node",
    "java": "\"C:/Program Files/Java/jdk-17/bin/java.exe\" -Dfile.encoding=UTF-8",

PowerShell

快速完成端口转发

netsh interface portproxy add v4tov4 `
listenaddress=0.0.0.0 `
listenport=2375 `
connectaddress=127.0.0.1 `
connectport=2375

查端口占用杀进程

netstat -aon | findstr :8080
taskkill /PID 39656 /F

自定义常用命令别名

notepad $PROFILE

function gacp {
    param (
        [string]$msg = "update"
    )
    git add .
    git commit -m $msg
    git push
}
#  删除当前文件夹下空文件夹
function rme {
    Get-ChildItem -Directory -Recurse | Where-Object { $_.GetFileSystemInfos().Count -eq 0 } | Remove-Item
}

Linux

Linux开辟虚拟内存（Swap）

free -h

Linux实现FRP内网穿透

的是让国内用户能连到一台没有公网 IP 的家庭电脑——用的是反向内网穿透:

SCA 2023.X — Nacos Bootstrap 配置失效问题排查与解决方案

Thu, 24 Jul 2025 22:40:26 +0800

Issue 来源：spring-cloud-alibaba#3931
影响版本：spring-cloud-alibaba 2023.0.1.3+

一、问题描述

在 Spring Cloud Alibaba 2023.X 版本中，将 Nacos 配置（包括 extension-configs、shared-configs 等）放在 bootstrap.yml / bootstrap.properties 中，配置中心的内容无法正常加载，但日志显示 bootstrap 文件本身已被读取。

将相同配置移到 application.yml 后，一切恢复正常。

二、根本原因

flowchart TD
    A[bootstrap.yml 被读取] --> B{SCA 版本判断}
    B -- 2023.0.1.2 及以前 --> C[✅ 正常加载 Nacos 配置中心]
    B -- 2023.0.1.3 及以后 --> D[❌ extension-configs / shared-configs 失效]
    D --> E[问题根源：SCA 2023.0.1.3 修改了配置加载优先级机制]
    E --> F[bootstrap 阶段注册的 Nacos PropertySource 被后续流程覆盖或丢弃]

简单来说：
SCA 2023.0.1.3 做了一次不向后兼容的内部变更，导致 bootstrap.yml 中的 Nacos 扩展配置在加载链路中被"丢掉"，而 application.yml 中的配置走的是新路径，不受影响。

Nacos 一些常用配置

Tue, 24 Jun 2025 19:01:02 +0800

bootstrap 配置

bootstrap.yaml

server:
  port: 10888
  tomcat:
    uri-encoding: UTF-8
spring:
  profiles:
    active: dev
  application:
    name: archive-service
  cloud:
    nacos:
      config:
        file-extension: yaml
        shared-configs:
          - data-id: shared-spring.yaml
            refresh: false
          - data-id: shared-redis.yaml
            refresh: false
          - data-id: shared-mybatis.yaml
            refresh: false
          - data-id: shared-logs.yaml
            refresh: false
          - data-id: shared-feign.yaml
            refresh: false
          - data-id: shared-logs.yaml # 共享日志配置
            refresh: false
#          - data-id: shared-feign.yaml # 共享feign配置
#            refresh: false

lia:
  jdbc:
    database: tb_archive

bootstrap-dev.yaml

spring:
  cloud:
    nacos:
      server-addr: 192.168.2.115:8848 # nacos注册中心
      discovery:
        namespace: f923fb34-cb0a-4c06-8fca-ad61ea61a3f0
        group: DEFAULT_GROUP
        ip: 192.168.2.115
logging:
  level:
    asia.liminality: debug

nacos 配置

shared-spring.yaml

spring:
  jackson:
    default-property-inclusion: non_null
  main:
    allow-bean-definition-overriding: true
  mvc:
    pathmatch:
      #解决异常：swagger Failed to start bean 'documentationPluginsBootstrapper'; nested exception is java.lang.NullPointerException
      #因为Springfox使用的路径匹配是基于AntPathMatcher的，而Spring Boot 2.6.X使用的是PathPatternMatcher
      matching-strategy: ant_path_matcher

shared-redis.yaml

spring:
  redis:
    host: ${lia.redis.host:192.168.2.115}
    password: ${lia.redis.password:github}
    lettuce:
      pool:
        max-active: ${lia.redis.pool.max-active:8}
        max-idle: ${lia.redis.pool.max-idle:8}
        min-idle: ${lia.redis.pool.min-idle:1}
        max-wait: ${lia.redis.pool.max-wait:300}

shared-mybatis.yaml

mySQL

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://${sh.jdbc.host:127.0.0.1}/${sh.jdbc.database}?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: ${lia.jdbc.username:root}
    password: ${lia.jdbc.password:794211}

mybatis-plus:
  configuration:
    default-enum-type-handler: com.baomidou.mybatisplus.core.handlers.MybatisEnumTypeHandler
  global-config:
    db-config:
      logic-delete-field: deletedAt
      logic-not-delete-value: "null"
      logic-delete-value: "now()"
      id-type: assign_id
      insert-strategy: not_null
      update-strategy: not_null

porstgreSQL

spring:
  datasource:
    driver-class-name: org.postgresql.Driver
    url: jdbc:postgresql://${lia.jdbc.host:192.168.2.115}:${lia.jdbc.port:5432}/${lia.jdbc.database}?useUnicode=true&characterEncoding=UTF-8&autoReconnect=true&serverTimezone=Asia/Shanghai
    username: ${lia.jdbc.username:postgres}
    password: ${lia.jdbc.password:github}
mybatis-plus:
  configuration:
    default-enum-type-handler: com.baomidou.mybatisplus.core.handlers.MybatisEnumTypeHandler
  global-config:
    db-config:
      logic-delete-field: deletedAt
      logic-not-delete-value: "null"
      logic-delete-value: "now()"
      id-type: assign_id
      insert-strategy: ignored
      update-strategy: ignored
      select-strategy: not_null

shared-logs.yaml

logging:
  pattern:
    dateformat: HH:mm:ss.SSS
    console: "%clr(%d{${LOG_DATEFORMAT_PATTERN}}){faint}-[${hostname}][%X{requestId:-sys}] %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n"
    file: "%d{${LOG_DATEFORMAT_PATTERN}}-[${hostname}][%X{requestId:-sys}]-${LOG_LEVEL_PATTERN:-%5p} ${PID:- } --- [%15.15t] %-40.40logger{39} : %m%n"
  file:
    path: "logs/${spring.application.name}"

shared-feign.yaml

feign:
  client:
    config:
      default: # default全局的配置
        loggerLevel: BASIC # 日志级别，BASIC就是基本的请求和响应信息
  httpclient:
    enabled: true # 开启feign对HttpClient的支持
    max-connections: 200 # 最大的连接数
    max-connections-per-route: 50 # 每个路径的最大连接数
  sentinel:
    enabled: true

微信小程序开发受苦指南

Wed, 23 Apr 2025 14:02:30 +0800

微信小程序和后端用户认证交互流程

微信小程序登录的核心流程：小程序拿临时凭证 code → 后端用 code 换 openid → 后端发自己的 JWT 给小程序。下面是整体流程图。

sequenceDiagram
    participant MP as 微信小程序
    participant WX as 微信服务器
    participant GW as gateway
    participant Auth as auth模块
    participant User as user-service
    participant DB as lia_user库

    MP->>WX: wx.login() 获取 code
    WX-->>MP: 返回临时 code
    MP->>GW: POST /auth/wx-login {code}
    GW->>Auth: 转发请求
    Auth->>WX: code2session(code)
    WX-->>Auth: 返回 openid + session_key
    Auth->>User: OpenFeign 查/建用户
    User->>DB: 按 openid 查询
    DB-->>User: 用户记录(或空)
    User-->>Auth: 返回 userId
    Auth->>Auth: 生成 JWT
    Auth-->>MP: 返回 token + 用户信息
    MP->>MP: 存入 Storage

关键点拆解

1. 小程序端拿 code（前端）

消息中间件面试题整理

Sun, 23 Mar 2025 13:21:54 +0800

消息队列通识

为什么需要消息队列

解耦
削峰填谷
异步调用

消息队列如何保持幂等

重复源泉
- 生产端重发
  - 发送ACK没有回复继续发送
- 消费端重复
解决方案
- 唯一消息ID，生产者发送时携带messageId
- 幂等表
- 状态机校验
- 乐观锁 / 版本号
- 分布式锁
核心原则
- 消费逻辑天然幂等

为什么需要消息队列

解耦
异步
削峰

消息队列的模型有哪些

点对点模型
发布订阅模型

如何保证消息不丢失

生产端
- ack
- broker 持久化
  - 生产环境副本因子 >= 3
消费端
- 手动提交 offset

如何保证消息有序

让需要保持有序的消息落到同一个分区
给唯一的key，且key以后不会重复
Kafka保证唯一分区内有序，跨分区无序

RabbitMQ

RabbitMQ 如何保证消息不丢失

哪些情况会丢失
- publisher -> exchange
  - 生产者确认机制
    - ack publish-confirm
    - nack publish-confirm
    - ack publish-return
    - 消息失败之后如何处理
      - 回调方法
      - 记录日志
      - 保存到数据库中然后定时重发
- exchange -> queue
  - 消息持久化
    - 交换机持久化
    - 队列持久化
    - 消息持久化
- queue
- queue -> consumer
  - 消费者确认机制

RabbitMQ 消息的重复消费问题是如何解决的

重复消费的原因

Spring Cloud 面试题整理

Sun, 23 Feb 2025 13:20:18 +0800

SpringCloud 问题

springcloud 五大组件

Eureka / nacos
Ribbon
Feign / dubbo
Hystrix / sentinel
Zuul/Gateway

服务注册和发现是什么意思，SpringCloud 如何实现服务注册和发现？

nacos 和 eureka 的区别？

相同点
- 服务提供者注册服务信息到注册中心
- 服务消费者定时从注册中心拉取
- 服务消费者对服务提供者进行远程调用
- 服务提供者临时实例采用心跳检查
  - 什么是临时实例？
    - 默认实例都是临时实例
    - 临时实例心跳模式
    - 非临时主动探测
    - 临时实例没有心跳会被剔除
    - 非临时不会被剔除
    - ephemeral: false 变成非临时实例
      - 非临时实例，nacos会主动询问服务提供者是否存活
不同点
- 非临时实例
- nacos集群AP，如果存在非临时实例，采用CP
- eureka采用AP
- nacos还有配置中心

你们项目中负载均衡是如何实现的？

Ribbon
Ribbon 负载均衡流程
1. 微服务发起请求
2. Ribbon 从注册中心拉取
3. 根据策略进行转发

Ribbon 负载均衡策略有哪些？

RoundRobinRule 简单轮询
WeightedResponseTimeRule 按照权重来选择服务器，响应时间越长，权重越小
RandomRule
BestAvailableRule 忽略短路的服务器，选择并发数较低的服务器
RetryRule 重试机制的选择逻辑（基于轮询）
AvailabilityFilteringRule 可用性敏感策略。先过滤非健康的，再选择连接数比较小的
ZoneAvoidanceRule 以区域可用的服务器为基础对服务器选择。

如果想自定义负载均衡策略，如何实现？

自己创建类实现 IRule 接口，再通过配置类或配置文件配置
@Bean IRule 全局生效
NFLoadBalancerRuleClassName 局部生效

什么是服务雪崩？如何解决这个问题？

服务雪崩
- 一个服务失败，导致整条链路都失败的情形
解决方案
- 降级（接口）
  - Feign 接口走fallback
- 熔断（整个服务）
  - Hystix
    - @EnableCircuitBreaker
    - 断路器关闭 - 打开 - 半开

你们的微服务是怎么监控的？

skywalking
- apache顶级项目
- 问题定位
- 性能分析
- 服务关系
- 服务告警

业务相关

项目中有没有做过限流？怎么做的？

限流情况

Java 面试题整理

Thu, 23 Jan 2025 08:50:54 +0800

集合

为什么数组索引要从 0 开始？从 1 开始不行吗？

回答大纲

数组在内存中是连续存储的，CPU 通过寻址公式访问元素
从 0 开始：a[i]_address = base_address + i * typeSize
从 1 开始：base_address + (i-1) * typeSize，多一次减法

正式回答

数组在内存中是连续存储的，CPU 通过寻址公式来访问指定下标的元素：a[i] 的地址 = 数组首地址 + i * 元素大小。当数组下标从 0 开始时，直接套用上述公式即可计算偏移量；如果下标从 1 开始，则需要先执行 i - 1 再做乘法，多了一次减法运算。虽然单次访问的差异可以忽略不计，但数组通常会出现在循环、遍历等高频访问的场景中，这笔额外开销会被无限放大。这也是 C 语言沿用下来的历史约定，Java 作为一门追求高效的系统级语言，继承了这一设计。

时间复杂度如何计算的？

回答大纲

口诀：常对幂指阶
常见复杂度
- 常数复杂度 O(1)：不随 n 变化
- 对数复杂度 O(logN)：二分查找、树操作

正式回答

时间复杂度用于衡量算法执行时间随数据规模 n 增长的变化趋势，是大 O 表示法下对最坏情况的抽象描述。常见的大小关系可用口诀"常对幂指阶"来记忆，即 O(1) < O(logN) < O(N) < O(N*logN) < O(N²) < O(2ⁿ) < O(n!)，越靠后算法越慢。

为什么国内大厂全面撤掉了公共 Docker 镜像源？

Mon, 23 Dec 2024 08:16:01 +0800

2024 到 2025 年这两年，阿里云、腾讯云、网易、科大讯飞，还有各大高校的公共 Docker 镜像站，基本上是一波接一波地关的关、限的限。到了 2026 年，“拉个镜像如渡劫"这句话已经不是玩笑了。

很多人第一反应是骂大厂抠门。但说实话，这事没那么简单。

合规这座山绕不过去

Docker Hub 是个全球开放的社区，任何人都能往上面推镜像，没有人在入口做内容审查。这就意味着里面什么都有——有漏洞的镜像、带恶意软件的镜像，乃至触碰国内监管红线的内容，全都混在里面。

问题在于，只要阿里云的服务器把这些东西同步下来，再转发给用户，阿里云就天然地成了"中间人”。在现行的监管逻辑下，平台不能说"我只是个镜子，内容不是我的"——你提供了传播通道，你就得负责。这种连带风险，没有哪家大厂愿意为一个免费服务去扛。

带宽这笔账算不过来

Docker 镜像这个东西和 npm、pip 那些包依赖有本质的不同——它就是重。一个普通的 Node.js 基础镜像几百 MB 起步，稍微带点 CUDA 或者 PyTorch 环境的，动辄就是好几个 GB。

国内用镜像源的群体又特别杂：开发者、CI/CD 流水线、还有成千上万台家用 NAS——群晖、极空间这些，很多人设置成定时自动更新，24 小时都在跑。这些流量全是公网出口流量，大厂一分钱都收不到，还得自己掏带宽的钱。

原本这种事情算是一种社区口碑投资，但现在各家都在降本增效，这种"纯出血、零转化"的项目，砍起来是毫不手软的。

大厂没有放弃加速，只是换了玩法

阿里云和腾讯云并没有把镜像加速这个能力整个下线，而是把它圈起来了。

现在的逻辑大概是这样的：你如果买了他们的 ECS，在内网环境里拉镜像，依然是快的、免费的。你如果想在公网用，那你得注册账号、开通 ACR（容器镜像服务），生成一个绑定了你身份的专属加速地址。一旦你的账号有异常，随时可以溯源和封禁。

换句话说，大厂的态度变成了：你是我的付费用户，或者至少是实名用户，我可以给你开小灶；你要是想匿名白嫖，那就没有这个服务了。

那现在大家怎么办？

目前社区里摸索出来的路子主要有几条。

一种是去找垂直的合规镜像站，比如开放原子基金会的 AtomHub，但它只收录了三百多个经过安全审计的基础镜像，能找到自己想要的东西的概率不高。还有一些商业和公益混合性质的服务，比如轩辕镜像、毫秒镜像，口碑还行，但也说不准能撑多久。

另一种是去开通阿里云或腾讯云的个人 ACR，拿到专属链接，老老实实实名用。

最彻底的做法，是自己在香港或者新加坡搞一台便宜的 VPS，用 Nginx 或者 Cloudflare Workers 自建一个反向代理，专供自己用，不对外开放。速度有保障，也不怕被人蹭流量拖垮。很多企业内部和有折腾精神的开发者，现在基本都走这条路了。

Cloudflare 业务学习

Sat, 23 Nov 2024 00:37:30 +0800

Spring 面试题整理

Sat, 19 Oct 2024 23:19:24 +0800

面试题从互联网各个角落收集而来

谈一谈 Spring IOC 的底层实现？

反射
工厂的价值
设计模式
关键的几个方法
- createBeanFactory
- getBean
- doGetBean
- createBean
- doCreateBean
- createBeanInstance(getDeclaredConstructor, newInstance)「方案选单」
- populateBean

flowchart TD
    A[开始] --> B["createBeanFactory()
创建 DefaultListableBeanFactory"]
    B --> C[加载 BeanDefinition
解析 XML/注解]
    C --> D["getBean(beanName)
外部调用入口"]

    D --> E["doGetBean(beanName)"]
    E --> F{从缓存获取单例?}
    F -->|是| G[返回缓存的 Bean]
    F -->|否| H["createBean(beanName, mbd)"]

    H --> I["doCreateBean(beanName, mbd)"]
    I --> J["createBeanInstance()
getDeclaredConstructor + newInstance"]
    J --> K["populateBean()
属性填充/依赖注入"]
    K --> L["initializeBean()
初始化回调"]
    L --> M[注册销毁方法]
    M --> N[返回完整 Bean 实例]

谈谈 SpringIOC 的理解，原理和实现？

IOC 思想
DI 实现手段
什么是容器什么是Bean
BeanDefination
- 从哪里读
  - XML
  - 注解
- 存哪里
  - 所有 BeanDefinition 都存在 DefaultListableBeanFactory 里的一个 Map 中

容器的生命周期

flowchart TD
    START([🚀 程序启动]) --> REFRESH["AbstractApplicationContext.refresh()"]

    REFRESH --> PHASE1

    subgraph PHASE1["🔵 第一阶段：准备工作"]
        direction TB
        A1["prepareRefresh()\n记录启动时间\n设置容器状态为「活跃」\n初始化环境变量"] --> A2
        A2["obtainFreshBeanFactory()\n创建 DefaultListableBeanFactory\n这是容器的核心仓库"] --> A3
        A3["prepareBeanFactory()\n注册基础 BeanPostProcessor\n注册 Aware 相关处理器\n注册默认环境 Bean（environment）"]
    end

    PHASE1 --> PHASE2

    subgraph PHASE2["🟢 第二阶段：加载 BeanDefinition（读图纸）"]
        direction TB
        B1["扫描 @ComponentScan 指定的包\n或读取 XML 配置文件"] --> B2
        B2["解析注解 / XML\n识别 @Component @Service\n@Repository @Controller @Bean"] --> B3
        B3["为每个 Bean 生成 BeanDefinition\n记录：类名、作用域、是否懒加载\n初始化方法、销毁方法、依赖关系"] --> B4
        B4[("存入 beanDefinitionMap\nkey = beanName\nvalue = BeanDefinition")]
    end

    PHASE2 --> PHASE3

    subgraph PHASE3["🟡 第三阶段：修改 BeanDefinition（修图纸）"]
        direction TB
        C1["invokeBeanFactoryPostProcessors()\n执行所有 BeanFactoryPostProcessor"] --> C2
        C2["ConfigurationClassPostProcessor\n处理 @Configuration @Import\n@PropertySource @ComponentScan\n👉 SpringBoot 自动装配在此触发"] --> C3
        C3["PropertySourcesPlaceholderConfigurer\n替换 BeanDefinition 中\n所有 ${xxx} 占位符为真实值"] --> C4
        C4[/"所有 BeanDefinition 最终确定\n图纸不再变动"/]
    end

    PHASE3 --> PHASE4

    subgraph PHASE4["🌸 第四阶段：注册 BeanPostProcessor（工人就位）"]
        direction TB
        D1["registerBeanPostProcessors()\n按优先级顺序注册\nPriorityOrdered → Ordered → 普通"] --> D2
        D2["AutowiredAnnotationBeanPostProcessor\n负责处理 @Autowired @Value"] --> D3
        D3["CommonAnnotationBeanPostProcessor\n负责处理 @PostConstruct @PreDestroy @Resource"] --> D4
        D4["AnnotationAwareAspectJAutoProxyCreator\n负责检测切面、生成 AOP 代理对象"] --> D5
        D5[/"所有工人就位\n等待 Bean 创建时介入\n此时不开工"/]
    end

    PHASE4 --> PHASE5

    subgraph PHASE5["🟣 第五阶段：容器基础设施初始化"]
        direction TB
        E1["initMessageSource()\n初始化国际化资源 i18n"] --> E2
        E2["initApplicationEventMulticaster()\n初始化事件广播器"] --> E3
        E3["onRefresh()\n⭐ SpringBoot 在此启动\nTomcat / Jetty / Undertow\nWeb 容器开始监听端口"] --> E4
        E4["registerListeners()\n注册所有 ApplicationListener\n监听容器事件"]
    end

    PHASE5 --> PHASE6

    subgraph PHASE6["🟠 第六阶段：实例化所有单例 Bean"]
        direction TB
        F1["finishBeanFactoryInitialization()\npreInstantiateSingletons()\n遍历所有非懒加载单例 BeanDefinition"] --> F2
        F2["逐个执行 getBean()\n触发每个 Bean 的生命周期\n实例化 → 属性填充 → Aware回调\n→ 前置处理 → init方法 → 后置处理"] --> F3
        F3[("所有单例 Bean 存入\nsingletonObjects 一级缓存\n✅ 全部就绪")]
    end

    PHASE6 --> PHASE7

    subgraph PHASE7["✅ 第七阶段：容器就绪"]
        direction TB
        G1["finishRefresh()\n清理启动时占用的资源\n初始化生命周期处理器"] --> G2
        G2["发布 ContextRefreshedEvent\n通知所有监听者：容器启动完成"] --> G3
        G3[/"容器进入运行状态\n可以处理业务请求"/]
    end

    G3 --> RUNNING([🎉 容器正常运行中])

    RUNNING -.->|"收到关闭信号\nCtrl+C / kill / close()"| PHASE8

    subgraph PHASE8["🔴 第八阶段：容器销毁"]
        direction TB
        H1["发布 ContextClosedEvent\n通知所有监听者：容器即将关闭"] --> H2
        H2["停止 Web 容器\nTomcat 停止接受新请求"] --> H3
        H3["执行所有 Bean 的销毁逻辑\n@PreDestroy → destroy() → destroy-method\n按注册顺序逆序销毁"] --> H4
        H4["清空所有缓存\nsingletonObjects 清空\nbeanDefinitionMap 清空"] --> H5
        H5["容器状态设置为「关闭」\nactive = false / closed = true"]
    end

    H5 --> END([💀 容器销毁完成])

    style START fill:#43A047,color:#fff
    style RUNNING fill:#43A047,color:#fff
    style END fill:#e53935,color:#fff
    style REFRESH fill:#1E88E5,color:#fff

bean 的生命周期

flowchart TD
    START([🌱 开始创建 Bean]) --> A

    A["① 实例化\nInstantiation\n反射调用构造方法\nnew 出空壳对象\n此时所有字段都是 null"] --> B

    B["② 放入三级缓存\nsingletonFactories\n提前暴露半成品\n为循环依赖做准备"] --> C

    C["③ 属性填充\npopulateBean()\n处理 @Autowired @Value\n把依赖的 Bean 注入进来"] --> D

    subgraph AWARE["④ Aware 回调"]
        direction TB
        D["BeanNameAware\n告诉 Bean 自己叫什么名字"] --> E
        E["BeanFactoryAware\n把 BeanFactory 塞给 Bean"] --> F
        F["ApplicationContextAware\n把 ApplicationContext 塞给 Bean"]
    end

    subgraph INIT["⑤ 初始化 initializeBean()"]
        direction TB
        G["前置处理\npostProcessBeforeInitialization()\n所有 BeanPostProcessor 挨个执行\n📌 @PostConstruct 在这里被调用"] --> INITMETHOD

        subgraph INITMETHOD["init 方法（按顺序执行）"]
            direction TB
            H1["第1个：@PostConstruct\n（已在前置处理中执行）"] --> H2
            H2["第2个：afterPropertiesSet()\n实现 InitializingBean 接口"] --> H3
            H3["第3个：init-method\n@Bean(initMethod='xxx') 或 XML 配置"]
        end

        INITMETHOD --> I

        I["后置处理\npostProcessAfterInitialization()\n所有 BeanPostProcessor 挨个执行\n⭐ AOP 代理在这里生成"]
    end

    AWARE --> INIT

    I --> J

    subgraph CACHE["⑥ 存入缓存"]
        direction TB
        J["从三级缓存 singletonFactories 移除\n从二级缓存 earlySingletonObjects 移除"] --> K
        K["存入一级缓存 singletonObjects\n✅ 完整 Bean 就绪"]
    end

    K --> READY([🎉 Bean 可以正常使用了])

    READY -.->|"容器关闭"| DESTROY

    subgraph DESTROY["⑦ 销毁阶段（容器关闭时）"]
        direction TB
        D1["第1个：@PreDestroy\n方法被调用"] --> D2
        D2["第2个：destroy()\n实现 DisposableBean 接口"] --> D3
        D3["第3个：destroy-method\n@Bean(destroyMethod='xxx') 或 XML 配置"]
    end

    D3 --> END([💀 Bean 销毁完成])

spring 三级缓存依赖流程

sequenceDiagram
    participant Spring as Spring容器
    participant L3 as 三级缓存
singletonFactories
    participant L2 as 二级缓存
earlySingletonObjects
    participant L1 as 一级缓存
singletonObjects

    Note over Spring: 开始创建 A

    Spring->>Spring: ① new A 空壳对象
    Spring->>L3: ② 存入 A 的 ObjectFactory lambda

    Note over Spring: 给 A 注入属性，发现需要 B

    Spring->>Spring: ③ new B 空壳对象
    Spring->>L3: ④ 存入 B 的 ObjectFactory lambda

    Note over Spring: 给 B 注入属性，发现需要 A

    Spring->>L1: ⑤ getBean(A)，查一级缓存
    L1-->>Spring: ❌ 没有

    Spring->>L2: 查二级缓存
    L2-->>Spring: ❌ 没有

    Spring->>L3: 查三级缓存
    L3-->>Spring: ✅ 找到 A 的 lambda！

    Spring->>Spring: ⑥ 执行 lambda
（需要代理则生成代理 A）
    Spring->>L2: ⑦ 早期引用放入二级缓存
    Spring->>L3: 删除三级缓存中的 A

    Note over Spring: B 拿到 A 的早期引用，B 完成初始化

    Spring->>L1: ⑧ B 放入一级缓存 ✅
    Spring->>L3: 删除三级缓存中的 B

    Note over Spring: 回到 A 的流程，B 已就绪，A 完成初始化

    Spring->>L1: ⑨ A 放入一级缓存 ✅
    Spring->>L2: 删除二级缓存中的 A

    Note over L1: 最终：一级缓存中有完整的 A 和 B ✅

情况	三级缓存	lambda 执行	二级缓存
无循环依赖，无 AOP	存了 lambda	❌ 不执行	不经过
无循环依赖，有 AOP	存了 lambda	❌ 不执行	不经过
有循环依赖，无 AOP	存了 lambda	✅ 执行	存原始对象
有循环依赖，有 AOP	存了 lambda	✅ 执行	存代理对象

spring bean 缓存的放置时间和删除时间

Spring Bean 三级缓存的放置与删除时间

缓存	存的是什么	放入时机	删除时机
三级 `singletonFactories`	Bean 的工厂 lambda	实例化完成后立刻放入	工厂被调用时（升级到二级）或 Bean 完成时
二级 `earlySingletonObjects`	早期暴露的半成品 Bean	三级工厂被调用的瞬间	Bean 完全初始化完成放入一级时
一级 `singletonObjects`	完整可用的 Bean	初始化全部完成后	容器关闭销毁时

BeanFactory 和 FactoryBean 的区别？

FactoryBean 是什么

public interface FactoryBean<T> {
    // 返回 Bean 的实例（可以是复杂创建逻辑）
    T getObject() throws Exception;

    // 返回 Bean 的类型
    Class<?> getObjectType();

    // 是否单例
    default boolean isSingleton() {
        return true;
    }
}

相同点
- 都是用来创建Bean对象的
不同点
- 使用 BeanFactory 创建对象的适合必须遵循严格的生命周期流程，太复杂了。如果想简单自定义某个对象的创建，同时想交给spring管理，那么必须实现 FactoryBean 接口
  - isSingleton 是否是单例对象
  - getObjectType 获取返回对象的类型
  - getObject 自定义创建对象的过程

对比维度	BeanFactory	FactoryBean
角色	容器/工厂接口	特殊的 Bean
功能	管理所有 Bean 的生命周期	自定义某个 Bean 的创建逻辑
定位	基础设施（IOC 容器）	业务扩展（创建复杂对象）
使用方式	由 Spring 框架实现和使用	由开发者实现，注册到容器中
常见实现	`DefaultListableBeanFactory`	`SqlSessionFactoryBean`、`ProxyFactoryBean`
谁创建谁	`BeanFactory` 创建并管理 `FactoryBean`	`FactoryBean` 创建业务对象

flowchart LR
    subgraph BeanFactory[BeanFactory - IOC容器]
        direction LR
        Bean1[普通 Bean]
        Bean2[普通 Bean]
        FB[FactoryBean
特殊 Bean]
    end

    FB -->|调用 getObject| Result[业务对象]

    User[开发者] -->|getBean| BF[BeanFactory]
    BF -->|返回| Bean1
    BF -->|返回| Bean2
    BF -->|返回 getObject 结果| Result
    BF -->|加 & 前缀| FB

Spring中用到的设计模式

单例模式
原型模式（指定作用域为prototype）
工厂模式
- BeanFactory
模板方法
- JdbcTemplate
- TransactionTemplate
- RestTemplate
- RedisTemplate
策略模式
- XmlBeanDefinitionReader
- PropertiesBeanDefinitionReader
观察者模式
- listener
- event
- multicast
适配器模式
- HandlerAdapter
装饰者模式
- BeanWrapper
责任链模式
- 使用aop的时候会先生成一个拦截器链
- SpringMVC 的filter责任链
代理模式
- 动态代理
委托者模式
- delegate

Spring AOP 底层实现原理

🥇 第一层：一句话定性（开场）

“Spring AOP 的底层本质是动态代理。Spring 在容器初始化 Bean 的时候，通过 BeanPostProcessor 机制拦截，判断这个 Bean 是否需要被增强，如果需要，就用动态代理生成一个代理对象，替换掉原始 Bean 注册进容器。后续所有对这个 Bean 的调用，实际上都是在走代理对象。”

MySQL 面试题整理

Thu, 19 Sep 2024 23:19:24 +0800

面试题从互联网各个角落收集而来

如何定位慢查询？

方案1
- 开源工具
  - Arthas
- 运维工具
  - Prometheus
  - Skywalking
方案2
- MySQL自带慢日志(mysql性能损耗)
  - 开启慢日志方法
    - /etc/my.conf
      - slow_query_log
      - long_query_time

SQL语句执行很慢，如何分析

慢的原因
- 聚合查询
- 多表查询
- 表数据量过大查询
- 深度分页查询
如何分析慢
- explain， desc 命令
  - 如何分析执行结果？
    - extra 的额外优化建议
      - using where; using index 查找使用了索引，需要的数据在索引列都能找到，不需要回表查询数据
      - using index condition 查找使用了索引
    - type
      - index，all 需要优化

了解过索引吗？什么是索引？

索引（index）是帮助 MySQL 高效获取数据的数据结构（有序）。在数据之外，数据库系统还维护着满足特定查找算法的数据结构（如 B+ 树），这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

帮助MySQL高效获取数据的数据结构

索引的底层数据结构了解过吗？

二叉搜索树
红黑树
B树
B+树
- 阶数更多，路径更短
- 磁盘读写代价B+树更低，叶子节点才能真正存储数据
- 便于扫库和区间查询，叶子节点是双向链表

什么是聚簇索引？什么是非聚簇索引？

聚簇索引
二级索引

什么是回表查询？

知道什么是覆盖索引吗？

通过该索引查询能够一次找到所有数据，且无需回表的，就是覆盖索引

MySQL超大分页怎么处理？

使用覆盖索引加上子查询

select * 
from tb_sku t,
  (select id from tb_sku order by id limit 9000000,10) a 
where t.id = a.id

索引创建的原则有哪些？

单表超过10万条数据且查询比较频繁的表建立索引
常常作为查询条件的字段要建立索引
使用区分度高的列作为索引，尽量建立唯一索引
字符串类型的字段长度较长可以建立前缀索引
尽量使用联合索引，减少单列索引
索引列使用NOT NULL方便优化器确定哪个索引更好用于查询

什么情况下索引会失效？

违反了最左前缀法则
查询范围右边的列，不能使用索引
索引列上进行运算操作，索引列失效
字符串不加单引号，索引失效（索引类型转换导致的失效）
字符串非尾部匹配，索引失效

谈一谈对SQL优化的经验

表设计优化
- 我们参考了阿里开发手册《嵩山版》
- 根据实际存储数值长短设计数据类型
索引的优化
SQL语句的优化
- select 语句务必指明字段名称
  - 为了覆盖索引
- 尽量用 union all 代替 union
- 避免对 where 子句中对字段进行表达式操作
- 能用 innerjoin 就不用 left join , right join。如必须，要以小表为驱动
主从复制，读写分离
分库分表

事务的特性详细说一说

并发事务带来哪些问题，如何解决这些问题？MySQL的默认隔离级别是？

并发事务的问题
- 脏读
  - 读已提交
- 不可重复读
  - 值问题
  - 可重复读
- 幻读
  - 数量问题
  - 串行化
隔离级别
- 未提交读
- 读已提交
- 可重复读*
- 串行化

undo log 和 redo log 的区别

缓冲池
数据页
redo log
- 物理
- 持久
undo log
- 逻辑
- 原子一致

事务的隔离性底层是如何保证的？

锁：排他锁
MVCC
- 多版本并发控制
- 依赖于
  - 隐式字段
    - DB_TRX_ID
    - DB_ROLL_PTR
    - DB_ROW_ID
  - undo log
    - 版本链
      - 版本链数据访问规则
  - readview
    - 快照读
      - Read Committed 每次 select都生成一个快照读
      - Repeatable Read 开启事务后第一个 select 语句才是快照读的地方
    - 核心字段
      - m_ids
      - min_trx_id
      - max_trx_id
      - creator_trx_id
    - RC隔离级别下，在事务中每次执行快照读时生成 ReadView

MySQL 的主从同步原理

核心：二进制日志
- BINLOG
  - DDL
  - DML 主数据库在事务提交时，变更记录写入 Binlog 从库 binlog -> 中继日志从库中继日志读取事件 -> 从库数据库

你们项目用过分库分表吗？

什么时候分库分表
- 单表数据量达到1000W 或者 20GB
- 优化解决不了性能问题
- IO、CPU瓶颈
如何拆分
- 垂直拆分
  - 垂直分库
    - 不同表拆分到不同库
    - 适用于微服务
  - 垂直分表
    - 不常用字段单独放在一张表
- 水平拆分
  - 水平分库
    - 一个库的数据拆分到多个库中
    - 路由规则
      - 根据id节点取模
      - 按id范围路由
  - 水平分表
    - 一个表的数据拆分到多个表中
新的问题
- 分布式事务一致性问题
- 跨节点关联查询
- 跨节点分页、排序函数
- 主键去重
解决方案
- 分库分表中间件
  - mycat
  - sharding-sphere

深入问题

为什么 InnoDB 主键建议自增？
为什么非自增主键会导致页分裂？
为什么 MyISAM 和 InnoDB 索引结构不同？
为什么 B+树适合磁盘而红黑树不适合？

JeecgBoot有多厉害？我的看法是

Mon, 19 Aug 2024 21:33:09 +0800

Redis LFU内存淘汰策略细究

Fri, 19 Jul 2024 13:10:54 +0800

Redis 的 LFU（Least Frequently Used，最不频繁使用）淘汰策略，是在 LRU 基础上做的“升级版”近似算法。它复用了对象头上同一个 24 位的 lru 字段，通过巧妙的编码和对数计数，用极小的内存代价，实现了对访问频率的近似跟踪。

下面从存储结构、计数器增减、淘汰决策到参数配置，逐一细究。

1. 24 位字段的位划分

每个 Redis 对象都有一个 lru 属性（24 位），在 LFU 模式下，它不再存放秒级时间戳，而是被拆成两段：

 高 16 位：最后衰减时间（Last Decay Time，单位：分钟）
 低  8 位：对数访问计数器（Logarithmic Counter，范围 0–255）

高 16 位：存储的是 (server.unixtime / 60) & 0xFFFF，即当前分钟时间戳的低 16 位。最大表示约 45 天，足够覆盖淘汰场景，即使回绕，只要间隔不超过 45 天就可以正确计算差值。
低 8 位：是一个 0–255 的频率计数器，但它不是访问次数的直接累加，而是经过对数平滑处理的“近似频率”。

当键被访问时，Redis 会调用 updateLFU()，先根据已流逝的时间衰减计数器，再概率性地递增计数器，最后把新的分钟时间戳和计数器重新编码写回 lru。

2. 计数器递增：对数增长

为了让 8 位计数器（0–255）既能表示低频也能区分高频，同时不让热门键快速打满，Redis 采用概率递增。

递增公式（源码级）：

double p = 1.0 / ((counter - LFU_INIT_VAL) * server.lfu_log_factor + 1);
if ((random() & 0xFFFF) < p * 0xFFFF) counter++;

LFU_INIT_VAL 默认为 5，新键的计数器初始值就是 5。
lfu_log_factor 是可配置的对数因子，默认 10。
随着 counter 增大，p 会越来越小，递增越来越难。

举例（factor = 10 时，典型访问次数与计数器值）：

软考系统架构师学习

Tue, 18 Jun 2024 12:51:35 +0800

本笔记基于考纲核心知识点整理，配合代码示例和记忆口诀，适合冲刺复习。

一、法律法规与标准化

1.1 著作权

类别	内容
不受保护	政府公文、法律条例、时事新闻
受保护	演讲稿、编写的图书、软件代码
归属时间	软件开发完成之日起自动产生
保护期限	50年（署名权、修改权、完整权永久保护）

著作权归属规则：

谁开发归谁
员工利用公司资源开发 → 归公司
职务作品无合同 → 归企业法人
改编作品 → 著作权归改编人

⚠️ 处理过程（算法逻辑）不属于软件著作权保护对象，只保护代码表达形式。

受时间限制的权利（50年）： 发表权、发行权、展览权、复制权
永久保护的权利： 署名权、修改权、保护作品完整权

1.2 其他知识产权

商标权：注册完成后才享有；保护对象为软件注册商标
专利权：专利注册完成后才享有

二、软件工程

2.1 软件开发模型对比

模型	适用场景	核心特征
瀑布模型	需求明确固定	阶段严格顺序，不可逆
增量模型	需求部分明确，需快速交付核心	分批次交付模块
原型模型	需求模糊，用户难以描述	先做原型再开发目标软件
螺旋模型	大型复杂高风险项目	每轮增加风险评估环节
喷泉模型	面向对象开发	无严格阶段划分，阶段可交叉迭代
V模型	可靠性要求高	开发与测试一一对应
W模型	质量要求高	开发与测试同步进行

瀑布模型阶段：
需求分析 → 系统设计 → 详细设计 → 编码 → 测试 → 维护
（每个阶段完成后才进入下一阶段）

螺旋模型四象限：
① 制定计划  ② 风险分析
③ 实施工程  ④ 客户评估

2.2 敏捷开发方法对比

方法	核心理念	关键特征
XP（极限编程）	把传统开发做到极致精简	结对编程、测试先行、持续集成
SCRUM	短周期冲刺	三会议（站会/计划/回顾），需求按商业价值排序
水晶开发	以人为本	最轻量灵活，重团队协作，文档少
FDD	特性驱动	五步：建模→功能清单→规划→设计→实现
ASD	适应性开发	猜测→协作→复盘，三个非线性阶段
DSDM	动态系统开发	八条原则，聚焦业务价值按时交付
开放源码	全球协作	高并行排障，代码公开

SCRUM 三大会议： 每日站会、迭代计划会、复盘回顾会

ElasticSearch 学习

Sat, 18 May 2024 12:51:05 +0800

1. 基础篇

1.1 起源：Lucene

Lucene：Apache 开源的 Java 全文搜索引擎类库。
优势：易扩展、高性能（纯 Java，可嵌入）。
缺点：使用复杂，需处理索引创建、查询解析等底层细节，无分布式支持。
Elasticsearch 基于 Lucene 构建，提供分布式、易用的 RESTful API。

1.2 技术栈（ELK）

Elasticsearch：存储、搜索和分析引擎。
Logstash：服务器端数据处理管道，采集、转换数据后发送至 ES。
Kibana：可视化平台，制作图表、仪表板，管理 ES。
Beats：轻量型数据采集器，发送到 Logstash 或 ES。

1.3 使用 Docker 安装

Elasticsearch（单节点）：

docker run -d --name es \
  -e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \
  -e "discovery.type=single-node" \
  -v es-data:/usr/share/elasticsearch/data \
  -v es-plugins:/usr/share/elasticsearch/plugins \
  --privileged \
  --network testNet \
  -p 9200:9200 -p 9300:9300 \
  elasticsearch:7.12.1

9200：HTTP API 端口
9300：内部节点通信端口
discovery.type=single-node：单节点模式（测试用）

Kibana：

docker run -d --name kibana \
  -e ELASTICSEARCH_HOSTS=http://es:9200 \
  --network=testNet \
  -p 5601:5601 \
  kibana:7.12.1

1.4 倒排索引（Inverted Index）

正向索引：文档 ID → 文档内容。适合根据 ID 精确查找，但做模糊搜索需遍历所有文档，效率低。
倒排索引：
- 文档（Document）：ES 中存储的一条 JSON 数据。
- 词条（Term）：文档经过分词后的最小单元。
- 结构：词条 → 文档 ID 列表（及位置、频率等）。
- 优点：快速定位包含某个词条的所有文档，实现高效全文搜索。

1.5 分词器（Analyzer）

将文本拆分为词条（term）的组件，由三部分组成：

AWS 学习

Thu, 18 Apr 2024 12:48:03 +0800

面向系统架构师认证，结合 Java 后端视角整理。核心思路：每个服务解决什么痛点、何时选它、和类似服务怎么区分。

一、存储 Storage

1.1 三种存储类型对比

类型	代表服务	访问单元	典型场景
块存储	EBS, EC2 Instance Store	数据块（Block）	数据库、OS 磁盘
文件存储	EFS, FSx	文件/目录树	多实例共享、NFS/SMB挂载
对象存储	S3	对象（Object + Key）	静态资源、备份、数据湖

块存储  → 像本地硬盘，OS看到的是裸设备，自己格式化挂载
文件存储 → 像 NAS，多台机器可以同时 mount 同一个目录
对象存储 → 像 HTTP PUT/GET 的 Key-Value，无目录概念，靠前缀模拟

1.2 Amazon S3

核心功能速查：

功能	说明	常见考点
Versioning	同一 Key 保留多个历史版本	开启后才能用 CRR / MFA Delete
CRR（跨区域复制）	异步复制到另一 Region	灾备 DR、降低延迟
Transfer Acceleration	通过 CloudFront 边缘节点加速上传	上传到遥远 Region 时使用
Lifecycle Policy	对象按年龄自动迁移存储类	节省成本核心手段
S3 File Gateway	本地 SMB/NFS 映射到 S3	混合云文件迁移
Intelligent-Tiering	自动在 Standard ↔ IA 间切换	访问模式不可预测时使用

S3 存储类选择决策树：

Spring Cloud 学习

Mon, 18 Mar 2024 12:46:51 +0800

1. 服务拆分与远程调用

1.1 为什么要拆分服务？

单体应用随业务增长面临：部署慢、扩展性差、技术栈固化等问题。微服务将其拆分为独立部署、独立扩缩容的小服务，每个服务只负责一个业务域。

拆分原则：

单一职责：每个服务只做一件事
高内聚低耦合：服务内部紧密，服务之间松散
数据独立：每个服务拥有独立数据库

1.2 用户登录流程（微服务视角）

Client → Gateway（鉴权） → 业务微服务A → 微服务B（OpenFeign）
                ↓
           Nacos（服务发现）

1.3 RestTemplate — 微服务间原始调用

RestTemplate 是 Spring 提供的 HTTP 客户端，可用于微服务间调用，但代码繁琐、不支持负载均衡，是 OpenFeign 出现前的过渡方案。

// 注册为 Bean，并开启负载均衡
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
    return new RestTemplate();
}

// 调用方式（服务名替代 IP:Port）
String url = "http://user-service/api/users/" + userId;
User user = restTemplate.getForObject(url, User.class);

⚠️ RestTemplate 已逐渐被 OpenFeign 取代，生产中优先选择 OpenFeign。

2. 服务治理 — Nacos 注册中心

2.1 解决的问题

微服务实例 IP / 端口动态变化，调用方无法硬编码地址。注册中心提供：

SSM框架学习

Sun, 18 Feb 2024 12:40:44 +0800

一、Spring IoC 容器

1.1 容器体系结构

BeanFactory（顶层接口）
    └── ApplicationContext（常用接口，扩展了BF）
            ├── ClassPathXmlApplicationContext（XML配置）
            ├── FileSystemXmlApplicationContext（文件路径XML）
            └── AnnotationConfigApplicationContext（注解配置）

BeanFactory vs ApplicationContext 核心区别：

特性	BeanFactory	ApplicationContext
Bean 初始化时机	懒加载（第一次 getBean 时）	饿加载（容器启动时）
功能	基础 IoC	IoC + 事件发布 + 国际化 + AOP等
使用场景	资源极度受限的嵌入式	99% 的业务场景

ApplicationContext 为什么没有 close()？
ApplicationContext 接口本身不定义 close()，是为了保持接口的通用性（不是所有容器都能/需要被关闭，如 Web 容器）。但其实现类 AbstractApplicationContext 实现了 Closeable，可以强转后调用，或用 ConfigurableApplicationContext 接口接收。

1.2 延迟加载（Lazy Loading）

// 注解方式：@Lazy 让 Bean 在第一次被使用时才初始化
@Bean
@Lazy
public HeavyService heavyService() {
    return new HeavyService();
}

// XML方式：
// <bean id="heavyService" class="..." lazy-init="true"/>

适用场景：初始化代价高、启动时不一定用到的 Bean（如某些连接池、第三方SDK客户端）。

MyBatis-Plus 学习

Tue, 16 Jan 2024 15:38:37 +0800

1. 简介

MyBatis-Plus（简称 MP）是一个 MyBatis 的增强工具，在 MyBatis 的基础上只做增强不做改变，为简化开发、提高效率而生。

核心特点：

无侵入：引入 MP 不会对现有 MyBatis 工程产生影响，犹如丝般顺滑。
损耗小：启动即会自动注入基本 CRUD，性能基本无损耗。
强大的 CRUD 操作：内置通用 Mapper、通用 Service，仅通过少量配置即可实现单表大部分 CRUD 操作。
支持 Lambda 形式调用：通过 Lambda 表达式，安全高效的编写查询条件，防止字段名误写。
内置代码生成器：通过少量配置即可生成 Mapper、Service、Controller 等代码。
内置分页插件：基于 MyBatis 物理分页，开发者无需关心具体操作，配置后即可使用。

官网：https://baomidou.com/

2. 基本用法

2.1 引入依赖

在 Maven 项目 pom.xml 中添加：

<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version> <!-- 请按最新版本 -->
</dependency>

如果是传统 Spring 项目，可引入 mybatis-plus 核心依赖并自行配置。通常 Spring Boot 项目直接使用 starter。

2.2 定义实体类

@Data
public class User {
    private Long id;
    private String name;
    private Integer age;
    private String email;
}

2.3 编写 Mapper 接口

继承 BaseMapper<T> 即可获得 CRUD 能力：

编程 on 洛克里亚的五度 博客

理解MySQL的MVCC

过家家项目：如何设计抢红包

抢红包的基本逻辑

v1（低并发）抢红包时实时使用二倍均值法计算，只使用MySQL

1. 红包创建流程

2. 红包金额分配策略

3. 数据持久化与防刷控制

4. 抢红包并发控制

5. 方法缺点

v2 （高并发）红包创建好了就已经固定了抢红包的数量和个数，加入Redis

Kafka 学习笔记

偏移量索引

高可用

ISR机制

DB MQ Redis 常见实践

一、读路径：Cache Aside(旁路缓存)

二、写路径：先写 DB，再删缓存

Flutter 相关面试题整理

一、Dart 基础

二、Flutter 框架核心原理

三、布局 & 基础组件

四、状态管理

五、路由 & 导航

六、动画

七、网络 & 本地存储

八、原生交互 MethodChannel

九、性能优化专项

十、图片、手势、输入、弹窗组件

十一、项目工程 & 打包适配

十二、进阶底层 & 疑难场景

十三、综合项目面试问答题

MyBatis 相关面试题整理

Mybatis 执行流程

Mybatis 是否支持延迟加载

Mybatis 的一级缓存 二级缓存 用过吗

React 相关面试题整理

一、JS 基础前置

二、React 基础核心概念

三、类组件生命周期（Class Component）

四、Hooks 全套（React16.8+）

五、React18 新特性

六、Diff 算法与渲染更新

七、组件通信方案

八、状态管理 Redux / Redux Toolkit / Zustand

九、React Router v6

十、表单处理

十一、样式方案

十二、工程化构建

十三、网络请求封装

十四、性能优化专题

十五、进阶底层原理

十六、项目实战场景题

Redis 相关面试题整理

你的项目的哪些场景使用了 redis

如果发生了缓存击穿、穿透、雪崩如何解决

redis 作为缓存， mysql的数据如何与redis进行同步？

介绍一下你的异步方案

Redis作为缓存，数据的持久化是怎么做的？

RDB 的执行原理？

AOF 的执行原理

RDB 和 AOF 对比

redis 的key过期了会立即删除吗

Redis 数据淘汰策略

数据库有1000万数据，redis只能缓存20万，如何保证redis中的数据都是热点数据？

Vue 相关面试题整理

一、JS/TS 前置基础

二、Vue2 基础核心

三、Vue2 组件通信

四、Vuex 状态管理

五、Vue Router 2/3

六、Vue2 进阶知识点

七、Vue3 核心升级（Composition API）

八、Vue3 模板、编译、Diff 优化

九、Pinia（Vue3 状态管理）

十、Vue Router 4（Vue3）

十一、Vue3 高级特性

十二、工程化 & 构建工具

十三、网络请求与封装

十四、性能优化专项

编程 on 洛克里亚的五度博客

Mybatis 的一级缓存二级缓存用过吗

微信小程序相关面试题整理