数据库的四种隔离级别，主要区别在于允许事务看到哪些并发修改，以及能够避免哪些并发异常。先说几个常见问题：脏读是读到了其他事务尚未提交的数据；不可重复读是同一事务两次读取同一行，结果发生变化；幻读是相同条件的两次查询返回了不同的记录集合。四种隔离级别从低到高分别是：READ UNCOMMITTED（读未提交）：允许读取其他事务尚未提交的修改，可能发生脏读、不可重复读和幻读，实际业务中很少使用。READ COMMITTED（读已提交）：只能读取已经提交的数据，解决脏读，但同一事务中两次查询可能看到不同结果。PostgreSQL 默认使用这个级别。REPEATABLE READ（可重复读）：保证同一事务中重复读取的数据保持一致，解决不可重复读。按照 SQL 标准仍可能出现幻读，不过 MySQL InnoDB 通过 MVCC、间隙锁等机制提供了更强的保护，具体还要区分普通查询和加锁查询。MySQL InnoDB 默认使用这个级别。SERIALIZABLE（串行化）：隔离程度最高，要求并发事务的结果等价于某种串行执行顺序，可以避免上述并发异常，但可能带来更多锁等待、事务冲突和重试开销。回到秒杀超卖的问题。假设库存只有 1 件，两个请求同时执行：SELECT stock FROM products WHERE id = 1001;都读到 stock = 1，然后各自判断库存足够并创建订单。如果读取和扣减之间没有正确的并发控制，就可能产生两笔成功订单。实际开发中，我更推荐使用数据库的条件更新，而不是先 SELECT 判断、再无条件扣库存：UPDATE products SET stock = stock - 1 WHERE id = 1001 AND stock >= 1;然后检查受影响行数。等于 1 才说明本次扣减成功；等于 0 则认为库存不足。并发更新同一行时，数据库会进行必要的写入冲突控制，后执行的请求不会仅凭之前读取到的库存继续扣减。扣库存与创建订单还应该放在同一个数据库事务中，任何一步失败都要回滚。另一种方案是在事务中使用 SELECT ... FOR UPDATE 锁定库存行，再判断和扣减。不过热点商品并发量很高时，锁竞争可能比较明显。所以仅仅把隔离级别从 READ COMMITTED 调到 REPEATABLE READ，并不能自动修复错误的库存判断逻辑。SERIALIZABLE 在事务逻辑完整且正确处理冲突的前提下可以提供更强保证，但也不是秒杀场景的首选性能方案。一般来说，条件扣减加事务就能解决单数据库中的基本超卖问题。实际系统还需要考虑请求幂等、重复下单和事务失败重试。如果使用 Redis 预扣库存、消息队列异步下单，还需要额外设计数据库与缓存之间的一致性和补偿机制。

JavaScript 模板字符串最实用的两个功能就是表达式插值和多行文本。它使用反引号包裹字符串，不需要像普通字符串那样频繁使用 + 拼接，也不用手动添加 \n 来实现换行。比如要生成一条用户消息：const name = "张三";const count = 3;const msg = 用户 ${name}，你有 ${count + 1} 条未读消息;这里的 ${} 不只能放变量，也可以放计算表达式、三元运算符或者函数调用，JavaScript 会先计算表达式，再把结果转换成字符串插入对应位置。多行文本也很方便，例如：const message = 用户：${name} 未读消息：${count} 状态：${count > 0 ? "待处理" : "已读"};这样得到的字符串会保留源码中的换行，不需要自己拼接多个字符串。实际写邮件模板、日志内容或者生成简单的文本报告时比较方便。不过有两个细节需要注意。第一，模板字符串会保留换行和缩进。如果代码为了美观在每一行前面加了空格，这些空格也会进入最终字符串，有时会导致输出格式不符合预期。第二，插值只是把表达式结果放进字符串，不会自动进行 HTML 转义。如果把用户输入直接插入 HTML 再交给 innerHTML，仍然可能产生 XSS 风险。另外，模板字符串还支持标签模板（Tagged Templates），可以在生成字符串前自定义处理插值内容，部分国际化和模板库会用到。总体来说，普通字符串配合拼接和转义字符也能实现大部分效果，但模板字符串写起来更直观，尤其适合需要动态变量和多行格式的场景。

11111111

Java 注解本质上是一种元数据，用来给类、方法、字段等程序元素添加额外信息。它本身不会执行任何业务逻辑，真正让注解发挥作用的是读取和处理这些信息的代码。比如 Spring 中的 @Transactional，单纯在方法上加这个注解，并不会让 JVM 自动开启事务，而是 Spring 通过事务管理和 AOP 代理等机制实现事务控制。注解能否在运行时通过反射获取，取决于 @Retention 的设置：SOURCE：只保留在源码阶段，编译后丢弃。CLASS：保留在 class 文件中，但通常无法通过运行时反射读取，也是默认值。RUNTIME：保留到运行时，可以通过反射读取。举个简单的例子，自定义一个注解：@Retention(RetentionPolicy.RUNTIME)@Target(ElementType.METHOD)@interface Track {}在方法上使用：@Trackpublic void doWork() {    System.out.println("执行任务");}运行时通过反射检查：Method method = Service.class.getMethod("doWork");if (method.isAnnotationPresent(Track.class)) {    System.out.println("记录操作日志");}method.invoke(new Service());这里假设 doWork() 是 Service 类的 public 方法。反射通过 getMethod 获取方法信息，通过 isAnnotationPresent 判断方法是否带有指定注解，再通过 invoke 动态调用方法。需要注意，@Track 本身并不会自动打印日志，日志行为是我们在反射处理逻辑中实现的。实际开发中也不一定每次都手动调用反射。像 Spring 这样的框架通常会在启动或运行过程中扫描注解，结合代理、拦截器等机制处理相应功能。所以可以这样理解：注解负责描述“这个方法有什么特殊含义”，反射负责在运行时读取这些信息并动态操作对象，具体做什么则由程序或框架决定。注解还可以由编译期处理器读取，并不是只能配合反射使用。

我觉得选择 Monorepo，关键不是项目数量，而是这些项目之间有没有比较强的依赖关系。如果前端、后端、公共组件库需要频繁一起修改，Monorepo 会比较合适。比如公共库修改了一个接口，可以在同一个 PR 中更新调用方，并统一运行测试，不用先发布新版本再挨个升级依赖。但如果几个项目基本独立，使用不同技术栈，发布周期也不一样，强行放在一起反而会增加 CI 配置和权限管理的复杂度。这种情况多个独立仓库可能更省事。实际落地时，我认为有几个地方需要注意：不要每次提交都全量构建。可以根据 Git 变更和项目依赖关系，只构建、测试受影响的部分。JS/TS 项目可以考虑 pnpm workspace 配合 Turborepo 或 Nx。公共依赖要有清晰边界。不要为了方便让所有包互相引用，否则后面很容易出现循环依赖。提前确定版本发布策略。多个包必须同步发布，可以采用统一版本；如果各自独立发布，可以考虑 Changesets 等工具管理版本和更新日志。CI 缓存也很重要，尤其是项目多了以后。合理缓存依赖和构建产物，通常比单纯增加构建机器更值得先尝试。还有一个容易忽略的点：Monorepo 不代表所有服务必须一起部署。代码可以放在同一个仓库，但各个应用仍然可以独立构建和发布。所以我的建议是，先判断项目之间的代码共享程度和协作频率。如果跨项目修改很频繁，Monorepo 的收益会比较明显；如果项目完全独立，就没有必要为了统一管理而迁移。

这三种方式主要区别在于 binlog 记录的内容不同，实际选择时，我觉得更应该关注数据一致性和日志开销。SBR（基于语句）：记录执行的 SQL。比如一次 UPDATE 修改了 10 万行，可能只需要记录一条语句，日志量比较小。但从库需要重新执行 SQL，如果语句存在不确定性，就可能导致主从结果不一致。RBR（基于行）：记录实际发生变化的行数据，从库直接应用这些变更，一致性更有保障。缺点是批量更新或删除大量数据时，binlog 可能明显增大。需要注意的是，ROW 模式下 DDL 仍然以语句形式记录。MBR（混合模式）：普通情况下使用 SBR，遇到 MySQL 判断不适合语句复制的操作时自动切换到 RBR。可以兼顾日志体积和复制可靠性，但也要注意，MySQL 不一定能识别所有可能产生不一致的情况。举个例子：UPDATE users SET token = UUID() WHERE token IS NULL;如果使用 SBR，主从分别执行 UUID()，生成的值就可能不同。而 RBR 记录的是主库已经生成的具体值，MIXED 遇到这种情况也会切换到行格式。实际生产环境中，我更倾向于使用 ROW。MySQL 8.0 默认就是 ROW，而且从 8.0.34 开始，binlog_format 已被标记为弃用，新部署没必要再优先考虑 STATEMENT 或 MIXED。可以通过下面的命令查看当前配置：SHOW VARIABLES LIKE 'binlog_format';另外，主从延迟也不是简单换个 binlog 格式就能解决的，还需要结合事务大小、网络状况和从库执行能力来排查。