服务端2月17日 18:53
TypeORM 支持哪些数据库？如何选择和配置？TypeORM 能连的数据库不少，但“支持”不等于“随便换个 type 就能无痛迁移”。MySQL、PostgreSQL、SQLite 这类关系型数据库是它最常见的使用场景；MongoDB 虽然也在支持列表里，但功能边界和 SQL 数据库明显不同。选型时要同时看驱动成熟度、团队经验、迁移能力、事务需求和生产环境的运维成本。
## TypeORM 官方支持的数据库有哪些
常见项目里会遇到的数据库大致可以分成三类。
| 数据库 | TypeORM `type` 值 | 常用驱动 | 适合场景 |
|---|---|---|---|
| MySQL | `mysql` | `mysql2...
乐闻
服务端2月17日 18:57
TypeORM 核心概念是什么？Entity 和 Repository 怎么用？TypeORM 的核心概念可以用一句话理解：用 TypeScript 类描述数据库结构，用 Repository、EntityManager 或 QueryBuilder 操作数据，再由 DataSource 统一管理连接、实体、迁移和事务。
如果只会 `save()` 和 `find()`，确实也能写业务；但一到关联查询、事务、迁移、多数据库配置，很多问题就会暴露出来。下面按实际项目里最常接触的顺序，把 TypeORM 的主要组件讲清楚。
## Entity：数据库表在代码里的样子
Entity 是 TypeORM 的基础。一个 Entity 类通常对应数据库里的一张表，类的属性...服务端2月17日 18:57
TypeORM 关系映射如何配置一对一、一对多和多对多？TypeORM 的关系映射，说白了就是把数据库里的外键、中间表和对象属性对应起来。真正容易出错的地方不在装饰器名字，而在谁拥有外键、什么时候自动加载、级联会不会误删数据。
下面按常用关系类型讲清楚：`OneToOne`、`ManyToOne` / `OneToMany`、`ManyToMany`，再补上查询、级联、删除策略和性能上的坑。
## 一对一关系：JoinColumn 放在拥有外键的一侧
`OneToOne` 适合两个实体一一对应的场景，比如一个用户只有一份个人资料。关键点是：**只有拥有外键的一侧需要写 `@JoinColumn()`**。
```typescript
...服务端2月17日 18:59
TypeORM QueryBuilder 如何写复杂查询？QueryBuilder 适合处理 Repository 的 `find` 选项不太好表达的查询，比如多表关联、复杂条件组合、聚合统计、子查询、批量更新删除。它的核心价值不是“写法更高级”，而是让你在 TypeScript 里拼出可控的 SQL，同时继续使用参数绑定、实体映射和事务能力。
如果只是按主键查一条数据，用 `repository.findOne()` 就够了；如果查询里开始出现 `JOIN`、`GROUP BY`、`HAVING`、`EXISTS` 或动态条件，QueryBuilder 会更清晰。
## 如何创建 QueryBuilder
最常用的写法是从 Reposi...服务端2月17日 19:00
TypeORM migrations 如何创建、运行和回滚？如果数据库结构只靠 `synchronize: true` 自动同步，开发环境看起来很省事，到了生产环境就容易变成“谁也说不清表结构为什么变了”。TypeORM migrations 解决的就是这个问题：把每一次表结构或数据修正写成可追踪、可回滚的脚本，让团队里的每台机器、测试库和生产库按同一套顺序变更。
简单说，migration 是数据库变更的版本记录。`up` 负责执行本次变更，`down` 负责撤回本次变更。TypeORM 会把已经执行过的迁移记录在数据库的 migrations 表里，之后只运行还没执行过的文件。
## migrations 主要解决什么问题
TypeOR...服务端2月17日 20:27
npm 工具有哪些？如何按项目场景选择？npm 生态里的工具很多，但项目里真正值得长期保留的，通常只解决几类问题：依赖更新、依赖清理、安全扫描、包体积控制、脚本编排、文档测试、构建开发、发布和 Git 工作流。
选工具时不要先问“有哪些”，而要先问“现在项目最卡在哪里”。依赖老旧就看 `npm-check-updates`；怀疑装了没用的包就跑 `depcheck`；发布前担心漏文件就检查 packlist；团队提交质量不稳定，再加 husky 和 lint-staged。
## 依赖更新：先看影响范围，再决定升不升
### npm-check-updates：批量检查 package.json 版本
`npm-che...服务端2月17日 20:45
Python 函数式编程怎么用才适合实际项目？## Python 函数式编程先解决什么问题
在 Python 里谈函数式编程，不是要把所有代码都写成一串看不懂的 `lambda`。它更适合处理这类问题：一批数据进来，经过过滤、转换、排序、聚合，最后得到一个新结果。
比如清洗接口返回的订单、统计日志里的错误类型、把配置项按规则合并。只要中间步骤能拆成几个独立的小函数，函数式写法就能让数据流向更清楚，也更容易测试。
Python 不是纯函数式语言，所以不用排斥循环、类和可变对象。更实际的做法是：在关键的数据处理逻辑里多用纯函数、少改共享状态，必要时用 `map`、`filter`、`reduce`、生成器和装饰器把重复逻辑收起来。...服务端2月17日 20:48
Python 元编程怎么用于框架开发和数据校验？## 先弄清楚：元编程到底在改什么
写 Python 框架时，经常会遇到一种需求：用户只写几行类定义，框架却能自动生成字段、校验规则、查询语句或接口对象。Django ORM、Pydantic、SQLAlchemy、表单库和很多 API SDK 都有这种味道。它们背后常用的就是元编程。
元编程的重点，是把“对象怎么创建、类怎么创建、属性怎么访问”这些过程开放出来。普通业务代码通常操作对象；元编程会再往前一步，操作类、方法、属性协议，甚至在运行时生成类。
常见工具包括：元类、动态属性、动态方法、描述符、`property`、`type()` 动态建类和类装饰器。它们适合做框架层能力，...服务端2月17日 20:51
Python 性能优化应该从哪里下手才有效？## 先确认：慢在哪里，别先改代码
Python 性能优化最容易走偏的地方，是一上来就把 `for` 循环改成列表推导式，或者把所有地方都加缓存。真正有效的顺序应该反过来：先测量，再定位瓶颈，最后只改最值得改的那一小段。
一个实用判断是：如果你说不清某段代码慢了多少、占总耗时多少、内存峰值在哪里，那现在还不是优化的时候。先把基准数据拿到手。
### 用 timeit 做小片段基准测试
`timeit` 适合比较一小段代码的耗时，比如列表查找和集合查找、字符串拼接和 `join`。它会重复执行代码，减少单次测量的抖动。
```python
import timeit
setup...服务端2月17日 21:41
Python 深拷贝和浅拷贝有什么区别，什么时候该用？## 先把“赋值”和“拷贝”分开
很多 Python 拷贝问题，最容易错在第一步：把赋值当成了复制。
赋值只是多了一个名字，两个变量仍然指向同一个对象。拷贝才会创建一个新对象。至于是只复制外层，还是连里面的对象一起复制，这就是浅拷贝和深拷贝的区别。
```python
original = [1, 2, 3]
assigned = original
assigned[0] = 99
print(original) # [99, 2, 3]
```
上面没有发生拷贝，`assigned` 和 `original` 指向同一个列表。
如果使用 `copy.copy()`，外层列...