AI Knowledge

外观

Python Web后端岗位定向面试准备 ​

30 秒结论｜ 这不是只考 Django 或 Flask API 开发的岗位，而是要求候选人独立承担管理系统模块的需求理解、方案设计、数据库与并发实现、联调、上线、故障处理和交付。准备时应以两个可追问的真实项目为主线，用 Python Web、MySQL、Redis/MQ、Docker/Linux 和 CI/CD 知识支撑；Kubernetes 先做到讲清原理和基本对象。

用词说明｜ 严格说，截图内容是 JD（Job Description，职位描述）；HC（Headcount）通常指招聘名额。本文依据用户提供的 JD 截图推断，不代表企业已公开题库。

目录 ​

1. 岗位画像与考察路径 ​

可以把这个岗位想成“带着工具箱去交房的后端工程师”：业务方给需求，候选人要把需求变成模块、表、接口和任务，还要装进容器、发布到环境、解决故障，最后向客户演示并交付文档。

这里的“户型图、管线、施工、验收和交房”，分别对应需求与方案、数据与接口、编码与联调、测试发布、文档与演示。这个类比只解释职责闭环，不能替代一致性、并发、安全和性能设计。

1.1 从 JD 用词反推 ​

最高概率：

  1. Python Web 真实经验：框架请求链、ORM、事务、中间件、异常和部署；
  2. MySQL：建模、索引、EXPLAIN、事务、锁、死锁和慢 SQL；
  3. Docker：Dockerfile、网络、挂载、日志、健康检查和回滚；
  4. 独立交付：真实模块、生产故障、联调与文档。

高概率：

  1. 进程、线程、协程、GIL、Event Loop；
  2. MQ 的幂等、重试、顺序、死信和积压；
  3. Redis 的缓存一致性、穿透、击穿、雪崩和持久化；
  4. Linux、Nginx、Gunicorn/uWSGI 和 CI/CD 排障。

中等概率：

  1. MongoDB 选型与文档模型；
  2. Kubernetes 的 Deployment、Service、Ingress、Probe；
  3. 策略、工厂、适配器、责任链等模式的真实使用。

1.2 面试官的评估路径 ​

图：从 JD 关键词到录用证据的追问路径

替代文本： 面试官从 Python Web、数据库、并发异步、部署运维和交付协作五类关键词出发，最终将知识收敛到一个真实模块和一次真实故障，判断候选人能否独立交付。

从 JD 关键词到录用证据的追问路径

读图结论： 技术点不会被孤立评分；框架、数据库和容器最终都要落到“真实模块”和“真实故障”两类证据。

2. 准备优先级 ​

2.1 P0：必须完成 ​

  1. 一份 90 秒岗位定向自我介绍；
  2. 一个从需求、设计、开发、联调到上线的真实业务模块；
  3. 一次按证据链完整复盘的生产问题；
  4. Django 或 Flask 选一个讲深，另一个讲清定位；只有 FastAPI 经验就如实说明，不冒充生产经验；
  5. 一条从慢 SQL 到执行计划、优化和回归的真实案例；
  6. 手写基本 Dockerfile，讲清日志、健康检查、数据迁移和回滚。

2.2 P1：高概率拉开差距 ​

  1. Python 对象模型、可变默认参数、拷贝、迭代器/生成器、装饰器、上下文管理器和 MRO；
  2. Django 的 Middleware、ORM 懒加载、select_related/prefetch_related、事务、迁移、认证；或 Flask 的 App Factory、Blueprint、上下文、扩展和 WSGI；
  3. Redis 缓存一致性、过期淘汰和高并发失效；
  4. 进程、线程、协程、GIL 和阻塞调用；
  5. MQ 的重复消费、幂等、重试、死信和 Outbox；
  6. Nginx + 应用 Server 请求链、Linux 资源排查和 CI/CD 门禁。

2.3 P2：有余力再准备 ​

  1. Kubernetes 基本对象、健康检查和滚动发布；
  2. MongoDB 文档模型、索引、副本集和聚合；
  3. 设计模式的一个正例和一个过度设计反例；
  4. 中等难度算法题；没有企业题库证据时，不优先冲刷 Hard 题。

2.4 Python 薄弱项专项策略 ​

如果 Python 是薄弱点，不要按语法手册从头平均学习。面试官更容易通过一小段代码判断候选人是否真正理解 Python，因此按以下四层准备：

  1. 第一层，保底语义： 可变与不可变、is 与 ==、哈希、作用域、默认参数、拷贝、异常；
  2. 第二层，语言机制： 可迭代对象、迭代器、生成器、闭包、装饰器、上下文管理器、MRO、描述符；
  3. 第三层，运行时与并发： 引用计数、循环 GC、GIL、线程安全、线程池、进程池、协程、Task、取消；
  4. 第四层，Web 工程： WSGI/ASGI、Worker、阻塞依赖、连接池、超时、日志、pytest、Mock 和性能剖析。

图：Python 后端薄弱项的递进补强路径

替代文本： 学习从对象和值语义开始，进入函数与协议，再进入 CPython 运行时和并发，最后落到 Web 请求、测试和生产排障；每层都通过口述、读代码和手写代码三种方式验收。

Python 后端薄弱项的递进补强路径

读图结论： 不要直接从 asyncio 或 Django 八股开始；对象语义和函数协议不稳，会在 ORM、并发和框架追问中连续失分。

每个知识点采用同一套训练法：

  1. 20 秒口述： 定义、机制和一个边界；
  2. 看代码： 不运行先预测结果，再执行验证；
  3. 手写： 写十至三十行最小实现，并补一个失败用例；
  4. 项目映射： 说明它在 API、任务、缓存或排障中的真实作用。

暂时不优先： 手写元类框架、深入 CPython C 源码、冷门魔术方法大全、复杂算法竞赛技巧。除非简历主动写了“精通 Python 底层”，否则这些内容的收益低于对象语义、并发和 Web 工程。

3. 两条项目证据主线 ​

3.1 真实业务模块 ​

从本人项目中选择线索流转、多租户授权、订单/退款、课时/约课、客户 SOP 或报表导出等一个闭环，准备：

  1. 业务角色、目标、状态与异常分支；
  2. 核心表、唯一约束、索引和事务边界；
  3. API、认证授权、幂等和错误码；
  4. 同步主流程与异步旁路；
  5. 本人主动做出的技术选择及备选方案；
  6. 测试、发布、监控、回滚和个人证据。

2～3 分钟口述模板： 这个模块解决的是……，我负责……。最难的不是写 CRUD，而是在……约束下同时保证……和……。我将它拆成状态、数据一致性、异步任务和发布四部分，选择……而没有选择……，因为……。我用……验证；当前能证明的是……，没有数据支持的指标不扩大表述。

3.2 一次生产问题 ​

优先选慢 SQL、锁等待、缓存不一致、重复消费、依赖超时、容器启动失败、502、内存增长或发布回滚。

口述模板： 系统出现……，影响……。我先用……止损，再根据 request_id、指标、日志、慢查询或发布版本定位到……。根因是……，长期修复是……，最后用……回归验证，并新增……告警、测试或 Runbook 防复发。

4. 高概率面试问题 ​

4.1 项目与岗位匹配 ​

Q01｜必问｜为什么你适合这个岗位？ ​

可直接口述： 我长期负责业务系统的需求拆解、数据建模、接口与异步任务、上线和排障。与岗位最匹配的不是某个框架名称，而是能把 Python Web、MySQL、Redis/MQ 和 Docker 组成可交付链路。我会用一个真实模块和一次故障说明具体贡献，并如实说明框架和指标的证据边界。

  • 考察点： 主线与岗位匹配；
  • 误区： 从技术名词开始念简历；
  • 追问： 选一个从需求跟到上线的模块。

Q02｜必问｜讲一个你独立负责的模块。 ​

可直接口述： 我按业务目标、本人边界、核心状态与数据、关键决策、异常处理、上线验证六步介绍。重点展开并发更新、多租户隔离或异步重试等真实难点，不把普通 CRUD 包装成亮点；最后给出代码、文档、测试或日志证据。

  • 考察点： 真实经验与个人贡献；
  • 追问： 重做一次会改变哪个决定？

Q03｜必问｜讲一次线上故障。 ​

可直接口述： 我先说明当时能看到的现象、影响和证据，再沿入口、应用、数据库、缓存/MQ、外部依赖分段排除。临时止损和长期修复分开，最后用回放、压测或故障注入验证，并固化成告警、测试或 Runbook。

  • 考察点： 生产证据链；
  • 误区： 只说“重启解决”；
  • 追问： 当时第一个被排除的假设是什么？

4.2 Python 与框架 ​

Q04｜必问｜Django、Flask 和 FastAPI 怎样选？ ​

可直接口述： Django 适合需要 ORM、Admin、认证和迁移等完整能力的管理系统；Flask 适合小型服务、既有 WSGI 系统或希望自行组合组件的团队；FastAPI 适合类型化 API 和 ASGI 异步生态。选择依据是业务能力、团队资产、依赖是否真异步和运维成本，不用“轻量”或“性能高”作为唯一理由。

  • 误区： Flask 天然更快，或 async def 自动提高吞吐；
  • 追问： 依赖都是阻塞的，异步接口有什么风险？

Q05｜高概率｜一个 HTTP 请求如何流转？ ​

可直接口述： 请求先经过反向代理和 WSGI/ASGI Server，再进入路由、中间件、认证授权、参数校验和业务服务，期间访问 ORM、缓存或外部依赖，最后序列化响应并记录日志指标。我会明确事务边界，不把外部 HTTP 调用长期放在数据库事务内。

  • 考察点： 请求链与事务；
  • 追问： 中间件抛异常时如何统一收口？

Q06｜高概率｜ORM 为什么产生 N+1？ ​

可直接口述： N+1 是先查一批主对象，遍历时又为每个关联对象发起查询。我会用 SQL 日志、APM 或查询计数测试发现；Django 中单值关联常用 select_related，多值关联常用 prefetch_related，同时评估结果集、内存和分页，避免盲目预加载。

  • 误区： 只说加索引；
  • 追问： 预加载为什么可能更慢？

Q07｜高概率｜GIL 对 Python Web 服务有什么影响？ ​

可直接口述： 常规 CPython 中，同一解释器进程通常只有一个线程执行 Python 字节码，所以纯 Python CPU 任务不应依靠多线程线性加速。I/O 等待时线程仍能叠加等待；CPU 热点应先优化算法，再考虑多进程、独立 Worker 或释放 GIL 的原生库。

  • 误区： GIL 让线程完全无用；
  • 追问： Worker 为什么不能无限增加？

Q08｜可能｜可变默认参数为什么危险？ ​

可直接口述： 默认参数在函数定义时求值，可变对象会被多次调用共享，导致状态串扰。通常用 None 作为默认值并在函数内创建新对象；确实需要共享缓存时才显式设计共享状态。

  • 追问： 闭包 late binding 会导致什么问题？

4.2.1 Python 薄弱项加练 ​

Q23｜必会｜is 与 == 有什么区别？ ​

可直接口述： == 判断两个对象的值是否相等，通常由 __eq__ 定义；is 判断是否引用同一个对象。None 这类单例应使用 is None，业务字符串和数字不能依赖驻留或小整数缓存用 is 比较，因为那是实现细节，不是值相等语义。

  • 考察点： 身份与相等性；
  • 追问： 自定义对象没有实现 __eq__ 时会怎样？

Q24｜必会｜list、tuple、set、dict 怎样选？ ​

可直接口述： list 是有序可变序列，适合按位置访问和动态追加；tuple 是有序不可变序列，可在元素都可哈希时作为键；set 用哈希实现去重和成员判断；dict 保存键值映射。选择依据是顺序、可变性、唯一性和访问模式，而不是笼统地说谁更快。

  • 考察点： 核心容器与复杂度；
  • 追问： 为什么包含 list 的 tuple 不能作为 dict 键？

Q25｜高概率｜什么是可哈希对象？ ​

可直接口述： 可哈希对象在生命周期内应保持稳定哈希值，并且相等对象必须具有相同哈希值，因此 dict 和 set 才能稳定定位桶。不可变不绝对等于可哈希，例如 tuple 只有在全部元素可哈希时才可哈希；自定义可变对象如果按可变字段计算哈希，会破坏容器不变式。

  • 追问： 重写 __eq__ 后为什么可能影响 __hash__？

Q26｜必会｜浅拷贝和深拷贝有什么区别？ ​

可直接口述： 浅拷贝创建新的外层容器，但内部嵌套对象仍共享引用；深拷贝递归复制可复制的子对象，并维护 memo 防止循环引用和重复复制。深拷贝不是默认更安全，它可能昂贵，也可能错误复制连接、锁或缓存；生产代码优先明确需要隔离的层级。

  • 考察点： 引用语义；
  • 追问： 二维 list 使用乘法初始化为什么容易串行修改？

Q27｜必会｜LEGB、闭包和 late binding 是什么？ ​

可直接口述： Python 名称解析按 Local、Enclosing、Global、Builtins 查找。闭包保存的是自由变量的引用环境，不是自动把循环变量的当时值复制进去，因此循环创建 lambda 时可能全部读取最终值；可用默认参数或额外工厂函数在创建时绑定。

  • 追问： nonlocal 与 global 分别修改哪一层？

Q28｜高概率｜*args、**kwargs 和仅限关键字参数有什么作用？ ​

可直接口述： *args 收集额外位置参数，**kwargs 收集额外关键字参数；函数签名中的 * 可强制其后的参数按关键字传递，/ 可声明仅限位置参数。生产接口不应为了“灵活”全部使用 kwargs，因为显式签名更利于类型检查、文档和兼容性管理。

  • 追问： 装饰器怎样完整转发参数并保留签名信息？

Q29｜必会｜Iterable、Iterator 和 Generator 有什么关系？ ​

可直接口述： Iterable 能通过 iter() 产生迭代器；Iterator 同时实现 __iter__ 和 __next__，每次返回下一个值并在结束时抛出 StopIteration；Generator 是由生成器函数或表达式创建的特殊迭代器，通过 yield 保存执行状态。生成器降低峰值内存，但通常只能消费一次，异常、关闭和外部资源仍需正确管理。

  • 追问： 为什么返回 generator 后数据库连接可能已经关闭？

Q30｜高概率｜装饰器的本质是什么？ ​

可直接口述： 装饰器本质是接收函数或类并返回替代对象的可调用对象，常用于日志、鉴权、重试和缓存。实现时用 functools.wraps 保留元信息，明确同步与异步函数边界，并避免无条件重试非幂等操作；复杂业务规则不应全部堆在装饰器中隐藏控制流。

  • 追问： 怎样写一个同时支持 sync 和 async 的装饰器？

Q31｜高概率｜上下文管理器解决什么问题？ ​

可直接口述： 上下文管理器通过 __enter__/__exit__ 或 contextmanager 把获取和释放资源绑定到一个明确作用域，即使发生异常也能清理文件、锁、事务或连接。__exit__ 返回真值会吞掉异常，因此必须谨慎；异步资源使用 async with 和异步上下文协议。

  • 追问： try/finally 与上下文管理器是什么关系？

Q32｜高概率｜try/except/else/finally 的执行顺序是什么？ ​

可直接口述： try 正常完成才执行 else；匹配到异常执行对应 except；finally 无论正常、异常还是 return 通常都会执行，用于清理资源。不要在 finally 中随意 return 或抛出新异常，否则可能覆盖原返回值或原异常；只捕获能处理的具体异常。

  • 追问： 为什么不建议 except Exception: pass？

Q33｜高概率｜CPython 怎样管理内存？ ​

可直接口述： CPython 主要依靠引用计数及时回收大多数对象，再用分代循环垃圾回收处理可回收的引用环；对象分配还涉及 Python 自身的内存分配器。引用归零不等于所有资源都应依赖析构及时释放，文件和连接仍应使用上下文管理器；内存不下降也可能是分配器复用，不一定是对象仍可达。

  • 考察点： 引用计数、循环引用和资源边界；
  • 追问： 怎样判断是对象泄漏还是 RSS 没有归还操作系统？

Q34｜高概率｜MRO 和 super() 怎样工作？ ​

可直接口述： MRO 是类属性和方法的查找顺序，多继承通常按 C3 线性化生成一致顺序。super() 不是固定调用“父类”，而是沿当前 MRO 调用下一个实现，所以协作式多继承要求各层保持兼容签名并继续调用 super；无法控制的复杂菱形继承通常优先改为组合。

  • 追问： 为什么直接写某个父类方法可能破坏协作式多继承？

Q35｜可能｜__new__ 和 __init__ 有什么区别？ ​

可直接口述： __new__ 负责创建并返回实例，在 __init__ 之前执行；__init__ 初始化已经创建的实例且应返回 None。不可变类型定制、单例或元类场景可能重写 __new__，普通业务类多数只需要 __init__；单例还要考虑并发、测试隔离和多进程边界。

  • 追问： 为什么进程内单例不能保证分布式系统只有一个实例？

Q36｜可能｜property 和描述符有什么关系？ ​

可直接口述： 描述符是实现 __get__、__set__ 或 __delete__ 的对象，用于控制属性访问；property 是常用的描述符封装，ORM 字段、方法绑定和校验框架也大量利用描述符协议。它适合维护属性接口和局部校验，但隐藏昂贵 I/O 会让一次看似普通的属性读取产生难以发现的性能问题。

  • 追问： 数据描述符和实例 __dict__ 谁的优先级更高？

Q37｜必问｜GIL 是否意味着 Python 代码线程安全？ ​

可直接口述： 不意味着。GIL 只限制常规 CPython 同一时刻执行 Python 字节码的线程数量，不保证一组业务操作原子；线程可能在多条字节码、I/O 或释放 GIL 的原生调用之间切换。共享可变状态仍需 Lock、Queue、不可变消息或减少共享设计，并通过并发测试验证。

  • 误区： 把单条表达式在某版本的偶然原子性当语言契约；
  • 追问： if key not in d: d[key] = value 为什么有竞态？

Q38｜必问｜Coroutine、Task 和 Future 有什么区别？ ​

可直接口述： 调用 async def 得到 Coroutine Object，它本身描述可挂起计算；Task 把协程注册到 Event Loop，使其可被调度并保存完成状态；Future 表示一个将来完成的结果，Task 是 Future 的一种高层实现。创建 Task 后要有所有权、取消、等待和异常回收，不能把后台任务丢给进程内存后不管。

  • 追问： await coroutine 与 create_task 的并发行为有什么不同？

Q39｜高概率｜异步取消和超时怎样正确处理？ ​

可直接口述： 超时通常通过取消等待中的 Task 实现，但取消是协作式的，代码要在 await 点传播取消，并在 finally 中释放连接、锁和临时资源。不要吞掉取消异常后继续执行副作用；对外部写操作超时还要区分明确失败和结果未知，先对账再决定是否重试。

  • 追问： 一个 Task 被取消时，它创建的子 Task 一定自动取消吗？

Q40｜高概率｜ThreadPoolExecutor 和 ProcessPoolExecutor 怎样选？ ​

可直接口述： ThreadPool 适合无法改成异步的阻塞 I/O，调用成本低且共享内存方便，但需限制队列和线程数；ProcessPool 适合可序列化的 CPU 密集任务，能利用多核并隔离故障，但有进程启动、序列化和数据复制成本。是否切池要以耗时分段和压测为依据，不能把每个同步函数都扔进线程池。

  • 追问： 为什么在 Web Worker 内再无限创建进程池会导致资源失控？

Q41｜高概率｜WSGI 与 ASGI 的主要区别是什么？ ​

可直接口述： WSGI 定义传统同步 Python Web 应用与 Server 的调用接口，适合成熟同步生态；ASGI 支持异步调用和连接生命周期，能表达 WebSocket、长连接和并发 I/O。ASGI 不会把同步数据库或第三方 SDK 自动变成非阻塞，部署时仍要设计 Worker、线程池、连接池、超时和背压。

  • 追问： Django 跑在 ASGI Server 上是否意味着所有 View 都异步？

Q42｜高概率｜怎样测试 Python Web 代码？ ​

可直接口述： 我将纯业务规则做快速单元测试，将数据库、缓存、MQ 和 HTTP 边界做集成或契约测试，再用少量端到端测试覆盖关键流程。pytest 的 fixture 管理可复用上下文，Mock 只替换真正的外部边界；重要故障还应注入超时、重复消息、事务回滚和并发竞争，避免测试只证明正常路径。

  • 误区： 过度 Mock 到测试只验证调用次数；
  • 追问： 数据库事务测试为什么可能掩盖提交后的回调问题？

4.3 MySQL、Redis 与 MongoDB ​

Q09｜必问｜联合索引怎样设计？ ​

可直接口述： 联合索引从真实查询模式出发，同时考虑等值、范围、排序、分组和回表成本。B+Tree 按列的字典序排列，缺少前导列时通常难以直接定位连续范围；是否使用最终以当前版本、数据分布和 EXPLAIN ANALYZE 为证据。

  • 追问： 范围条件后的列一定完全不能利用吗？

Q10｜必问｜怎样排查慢 SQL？ ​

可直接口述： 我先确认时间窗口、参数、返回行数和数据分布，再看慢日志、锁等待和 EXPLAIN ANALYZE，判断是扫描过多、估算失真、回表、排序/临时表还是 N+1。优化后用相同数据比较计划、耗时、读取行和写入代价。

  • 误区： 看到慢就加索引；
  • 追问： 加索引后优化器仍不用，可能是什么原因？

Q11｜高概率｜MVCC、隔离级别和锁怎样配合？ ​

可直接口述： MVCC 让一致性读根据 Read View 和版本链获得可见数据，减少普通读写互斥；当前读和更新仍需锁。隔离级别决定可见性边界，业务还需唯一约束、乐观锁、固定更新顺序和短事务保证不变式。

  • 追问： 如何根据死锁日志定位 SQL 和加锁顺序？

Q12｜高概率｜缓存与数据库怎样保持一致？ ​

可直接口述： 读多写少场景常用 Cache-Aside，更新时先提交数据库再删除缓存，并用 TTL、版本号或异步重试收敛短暂不一致。它不是 MySQL 与 Redis 的原子事务；账务、库存等权威状态仍以数据库和业务约束为准。

  • 追问： 删除缓存失败怎么办？热 Key 失效怎么办？

Q13｜可能｜什么数据适合 MongoDB？ ​

可直接口述： MongoDB 适合结构有弹性、常按聚合根整体读写且跨聚合关系较少的文档数据。强关联、复杂事务和高频多表分析通常更适合关系库；不能因为字段像 JSON 就直接选择 MongoDB。

  • 追问： 文档持续增长会有什么风险？

4.4 并发、MQ 与可靠性 ​

Q14｜必问｜进程、线程和协程怎样选？ ​

可直接口述： 进程适合隔离和多核；线程适合复用阻塞依赖的 I/O 并发，但要处理竞态；协程适合大量非阻塞 I/O，由 Event Loop 在 await 点协作切换。我按 CPU/I/O 性质、依赖是否真异步、隔离需求和压测结果组合使用，不追求无限并发。

  • 误区： 协程等于多核并行；
  • 追问： Event Loop 中调用阻塞 SDK 会怎样？

Q15｜必问｜MQ 重复消费怎样处理？ ​

可直接口述： 系统一般按至少一次投递设计，消费者用业务唯一键或 Inbox 记录保证幂等，并将业务更新和处理记录放在同一事务内。可重试错误有次数和时间预算，毒消息进入死信队列并告警；不把 Broker 投递语义说成业务恰好一次。

  • 追问： 业务成功但 ACK 丢失会怎样？提交数据库后发消息失败怎么办？

4.5 Docker、Linux、CI/CD 与 K8s ​

Q16｜必问｜怎样容器化并发布 Python Web 服务？ ​

可直接口述： 我使用锁定依赖的精简镜像和非 root 用户，利用分层缓存安装依赖，再复制代码并设置应用 Server。配置和密钥外部注入，数据使用持久存储；发布前做迁移、健康检查和回归，发布后核对版本、指标和日志，失败时回滚镜像并保证 Schema 兼容。

  • 追问： 迁移已执行但应用要回滚怎么办？

Q17｜高概率｜发布后出现 502 怎么排查？ ​

可直接口述： 我先确认影响面、开始时间和发布变更，再沿 DNS/负载均衡、Nginx、应用监听、容器网络、健康检查和下游依赖逐段验证。重点看反代日志、进程存活、地址端口绑定、超时和资源限制；与发布强相关时先按预案回滚止损。

  • 误区： 用盲目重启代替定位；
  • 追问： 只在容器内可访问时检查什么？

Q18｜高概率｜CI/CD 流程应包含什么？ ​

可直接口述： 流水线至少包含依赖锁定、静态检查、单元/集成测试、镜像构建与扫描、环境配置、发布审批、健康验证、版本标识和回滚。数据库迁移采用前后兼容策略，密钥不进代码和镜像；Job 绿色不等于线上版本与健康状态已确认。

  • 追问： 怎样让旧应用兼容新 Schema？

Q19｜可能｜Deployment、Service、Ingress 分别做什么？ ​

可直接口述： Deployment 管理 Pod 副本、滚动更新和回滚；Service 为动态 Pod 提供稳定服务发现和访问入口；Ingress 通常按域名和路径把 HTTP/HTTPS 流量转给 Service。还需配置 Probe、资源请求与限制、ConfigMap/Secret 和可观测性。

  • 追问： readiness 与 liveness 配反会怎样？

4.6 权限、联调与设计 ​

Q20｜高概率｜管理系统权限怎样设计？ ​

可直接口述： 我将身份认证、功能权限、数据范围和资源归属分开。RBAC 处理用户—角色—权限，租户、部门和本人数据范围在查询和业务服务中统一强制；前端隐藏按钮不是安全边界，后端必须 Fail Closed，并记录关键操作审计。

  • 追问： 租户、部门和本人范围怎样落到 SQL？

Q21｜高概率｜怎样与前端、测试和客户联调？ ​

可直接口述： 开发前确认用例、字段语义、状态机、错误码和兼容性，用 OpenAPI 或等价契约作为基线。分歧回到可重现请求、request_id、环境、版本和数据，不说“我这里没问题”；交付时提供功能、部署、变更、限制和回滚说明。

  • 追问： 临时要求与原验收标准冲突怎么办？

Q22｜可能｜项目中用过什么设计模式？ ​

可直接口述： 我从真实问题出发，例如用策略隔离渠道规则、用适配器统一第三方接口、用责任链组合校验步骤。回答时说明使用前的问题、使用后的替换边界和抽象成本；只有一种实现时，不为了套模式过度设计。

  • 追问： 你删除过哪个不必要的抽象？

5. 现场编码与系统设计 ​

5.1 可能的编码题 ​

  1. 实现带参数的计时或重试装饰器，保留函数元信息并限定可重试异常；
  2. 用生成器流式处理大文件；
  3. 用有界 Queue 实现生产者—消费者和正确退出；
  4. 找出可变默认参数、late binding、浅拷贝或竞态 Bug；
  5. 实现 LRU、去重保序、分页或区间合并；
  6. 设计幂等创建接口：唯一约束、事务、响应重放和冲突处理。

5.1.1 Python 必练的十个最小实验 ​

每题控制在 10～30 行，先写测试再实现：

  1. 修复“二维列表乘法初始化”造成的共享引用；
  2. 修复循环 lambda 的 late binding；
  3. 实现保留元信息、支持参数的同步装饰器；
  4. 为异步函数实现超时与 finally 清理；
  5. 实现一个类式上下文管理器，异常时不误吞异常；
  6. 使用生成器逐行过滤大文件，并确保文件生命周期正确；
  7. 使用 queue.Queue、哨兵和 task_done/join 实现有界生产消费；
  8. 对共享计数器制造竞态，再用 Lock 或消息传递修复；
  9. 用 ThreadPoolExecutor 包装阻塞 I/O，并限制并发与总超时；
  10. 用 pytest fixture、参数化和 Mock 测试一个调用外部 API 的服务层。

验收标准：

  1. 能在不运行代码时预测正常路径和异常路径；
  2. 能解释为什么原代码错误，而不只给出改法；
  3. 至少包含一个失败测试；
  4. 能说明放进 Web Worker 后的资源、取消和线程安全边界；
  5. 能说明何时不应该使用这个方案。

5.2 可能的 SQL 题 ​

  1. 查询每个用户最近一条订单或操作记录；
  2. 查询连续多天活跃用户；
  3. 为多条件列表设计联合索引；
  4. 分析包含 JOIN、ORDER BY 和 LIMIT 的执行计划；
  5. 解释深分页与 Keyset/Seek Pagination。

5.3 系统设计：大数据量报表导出 ​

可直接口述： 我先确认数据量、时效、格式、租户权限、一致性快照、保留时间和并发量。小导出可同步流式返回；大导出创建带幂等键的任务并提交 MQ，Worker 用稳定游标分批读取、流式写入对象存储，最后返回带时效和权限的下载地址。系统还要有状态、进度、取消、超时、重试、去重、并发限额、清理和审计，严禁跨租户导出。

连续追问：

  1. 导出期间数据变化，是要快照还是最终值？
  2. Worker 完成但 ACK 丢失怎么办？
  3. 单租户大量提交怎样公平限流？
  4. 怎样避免内存爆掉、深分页和数据库压垮？
  5. 文件已上传但任务状态未更新怎样对账？

6. 冲刺计划 ​

6.1 有七天 ​

  1. 第 1 天：自我介绍、真实模块、生产故障和证据；
  2. 第 2 天：Python 核心、并发、GIL，手写三题；
  3. 第 3 天：深挖一个 Web 框架，准备三框架选型；
  4. 第 4 天：MySQL 索引、执行计划、事务、锁和五道 SQL；
  5. 第 5 天：Redis、MQ、幂等、缓存一致性；
  6. 第 6 天：Docker、Linux、Nginx、CI/CD 和 K8s 基础；
  7. 第 7 天：完整模拟，只修复答不出、证据不足、表达不清。

6.2 只有一天 ​

  1. 优先完成自我介绍、一个模块和一次故障；
  2. 复习框架请求链、ORM/N+1、索引/事务、缓存一致性和 MQ 幂等；
  3. 手写 Dockerfile，口述一次 502 排查和回滚；
  4. 做 45 分钟模拟：自我介绍 2 分钟、项目 15 分钟、技术 20 分钟、反问 8 分钟；
  5. 不再深挖 MongoDB、K8s 调度器或复杂设计模式。

6.3 Python 薄弱项五天加练 ​

每天约 2.5 小时，按“口述 40 分钟、看代码 40 分钟、手写 60 分钟、复盘 10 分钟”执行。

  1. 第 1 天，对象语义： 可变性、身份/相等、哈希、容器、拷贝、默认参数和作用域；完成 Q23～Q28；
  2. 第 2 天，函数与协议： 迭代器、生成器、装饰器、上下文、异常、MRO 和描述符；完成 Q29～Q36；
  3. 第 3 天，运行时并发： 引用计数、GC、GIL、线程安全、Task、取消和线程/进程池；完成 Q37～Q40；
  4. 第 4 天，Web 工程： WSGI/ASGI、请求链、ORM、Worker、连接池、pytest 和 Mock；完成 Q04～Q06、Q41～Q42；
  5. 第 5 天，闭卷验收： 随机抽十道题，每题先答 30 秒再追问 90 秒；手写装饰器、生成器、生产消费、异步取消四选二，并把一个知识点映射到真实项目。

通过标准：

  • 十道随机题中至少八道能在 30 秒内给出“结论、机制、边界”；
  • 两道手写题能运行，且各有一个失败用例；
  • 面对不会的版本或源码问题，能明确边界并给出验证方法；
  • 不再出现“GIL 让线程无用”“async 自动提高性能”“tuple 一定可哈希”等典型错误。

7. 反向提问 ​

建议选三至四个：

  1. 入职前三个月最希望该岗位交付什么？
  2. 主框架、Python 版本和数据库版本是什么？
  3. “系统对接方”是内部团队、客户 IT 还是第三方厂商？
  4. 是标准云环境、客户私有化部署，还是两者都有？
  5. 开发与运维边界如何划分，是否轮值、出差或现场支持？
  6. 如何做代码评审、自动化测试、发布审批和回滚？
  7. 当前最大技术债是什么，新功能与存量维护各占多少？

风险边界： “开发 + 运维 + 演示 + 文档”可能代表端到端所有权，也可能代表职责过宽；“客户侧需求”和“演示”还可能意味着私有化交付、售前售后或现场支持，应主动确认。

8. 总结 ​

一句话记忆： 用“一个真实模块 + 一次真实故障”证明能将 Python Web、数据、并发和部署组成可交付系统。

  • 深挖一个真实使用过的 Django 或 Flask，不必同时精通两者；
  • Python 薄弱项按对象语义、函数协议、运行时并发、Web 工程四层补强，并用口述、读代码、手写代码三种方式验收；
  • MySQL、Docker 和项目交付是 JD 最明确的硬门槛；
  • 并发和 MQ 要讲选择、幂等、背压和失败边界；
  • 所有结论落到代码、日志、测试、文档或真实数据，不虚构经验和指标。