服务端面试题手册

Dify 的团队协作和权限管理，核心是用工作空间隔离资源，用角色控制操作范围，再用 API Key、日志和审计手段约束生产访问。回答这类问题时，不能只列 Owner、Admin、Editor、Viewer，还要说明企业里怎么分组、怎么管知识库、怎么防止误改生产应用。比较稳的配置思路是：按业务或环境划分工作空间，按职责分配最小权限，生产应用限制编辑入口，外部系统统一使用专用 API Key，不用个人账号长期集成。追问Dify 常见角色应该怎么分配？Owner 通常只给平台负责人或少数管理员，负责工作空间生命周期、关键配置和最终兜底。Admin 可以管理成员、模型、应用和资源，但不建议给太多人，否则权限边界会失控。Editor 适合应用构建者、提示词工程师和知识库维护人员，Viewer 适合业务评审、测试和只需要查看效果的人。取舍是协作效率和安全之间的平衡：权限给少了会拖慢迭代，给多了容易误删应用、泄露日志或改坏生产配置。企业里应该按团队还是按环境划分工作空间？如果公司业务线很多，优先按业务线或部门划分工作空间，能让知识库、应用和成员关系更清楚。如果生产安全要求高，可以再把测试和生产拆开，至少保证生产应用只有少数人能编辑。边界是工作空间拆得太细会带来重复配置，比如模型供应商、通用知识库和成员管理都要维护多份。比较实用的做法是核心生产应用单独隔离，普通实验应用放在团队空间里，并用命名规范标明 dev、test、prod。API Key 权限管理有哪些坑？最大的坑是用个人账号生成的 Key 接入生产系统，员工离职、换岗或误删时会影响线上服务。更好的方式是为应用或系统单独创建集成用 Key，记录用途、负责人、创建时间和轮换周期。还要避免把 Key 写死在前端、文档截图或日志里，必要时通过环境变量、密钥管理服务或 CI/CD Secret 注入。取舍在于轮换越频繁越安全，但也会增加运维成本，所以至少要对生产 Key 建立定期检查和泄露应急流程。知识库和应用权限应该怎么管？知识库通常比应用更敏感，因为里面可能有合同、客户资料、内部制度或产品路线图。配置时要明确谁能上传、删除、重新索引和绑定知识库，避免普通编辑者把测试资料接到生产应用。应用权限则要区分查看、调试、编辑、发布和调用，尤其是带外部工具的工作流，错误配置可能触发真实业务操作。踩坑是只管页面编辑权限，不管知识库数据来源和工具调用权限，结果模型回答泄露了不该看的内容。如何做审计和日常权限复查？企业级配置不能只在上线当天做一次，至少要按月或按季度复查成员、角色、API Key 和应用访问日志。操作上可以导出成员清单，与组织架构或 IAM 系统比对，清理离职、转岗和临时项目成员。对高风险应用，要关注谁修改了提示词、知识库、模型参数和工具配置，并保留变更记录。Dify 自带能力能覆盖一部分协作和日志需求，但如果要满足合规审计，最好接入公司统一身份认证、网关日志和集中审计平台。

Dify、LangChain、Flowise 不是简单的谁更强，而是抽象层级不同。Dify 更像面向团队交付的 AI 应用平台，提供可视化编排、知识库、模型接入、API 发布、日志和权限能力；LangChain 更像开发框架，适合写代码做深度定制；Flowise 更偏可视化链路编排，适合把 LangChain 类能力拖拽出来快速验证。面试回答时，关键不是背功能清单，而是能根据团队技术能力、上线速度、可控性和运维成本做取舍。追问Dify 相比 LangChain 的核心优势是什么？Dify 的优势是开箱即用和团队协作成本低，产品、运营或解决方案同学也能参与调提示词、建知识库、看日志。LangChain 的优势是代码可控性强，复杂 Agent、私有工具协议、特殊记忆策略或深度业务逻辑更容易定制。取舍很直接：如果目标是快速上线一个客服、知识库问答或内部助手，Dify 更省时间；如果目标是把 LLM 深度嵌入核心业务系统，LangChain 或自研框架更灵活。踩坑是把 Dify 当成万能低代码平台，遇到复杂状态机、强事务或多系统编排时，仍然需要后端工程兜底。Dify 和 Flowise 的区别在哪里？Flowise 更突出流程编排体验，适合快速把提示词、模型、向量库、工具节点连起来验证想法。Dify 除了编排，还把应用发布、会话日志、知识库管理、模型供应商配置、权限和 API 调用这些上线后必须处理的东西做进了平台。边界是，Flowise 在轻量实验里更直接，Dify 在多人维护和生产交付里更完整。常见选择是：个人或小团队先用 Flowise 验证链路，确定要给业务部门长期使用时，再考虑 Dify 或自研平台来承接治理。什么时候不应该选 Dify？如果项目需要非常细的底层控制，例如自定义推理调度、复杂 Agent 记忆、跨多个内部系统的事务一致性，Dify 可能会显得不够自由。如果团队已经有成熟的 AI 中台、观测体系和发布流程，直接接入 LangChain、LlamaIndex 或内部框架可能更贴合现有架构。另一个边界是性能和成本，Dify 能提升开发效率，但不自动保证低延迟，模型、检索、外部工具调用仍要单独优化。面试里可以补一句：选 Dify 是买平台效率，不是放弃工程治理。企业落地时怎么做平台选型？先看应用类型：知识库问答、客服机器人、销售助手这类标准应用，Dify 通常更合适；研究型 Agent、强业务逻辑自动化、复杂多工具规划，则更适合代码框架。再看团队结构，如果业务方需要频繁调流程，低代码平台能减少研发排队；如果只有工程团队维护，代码方式更容易纳入 CI/CD 和代码审查。还要看部署要求，Dify 支持私有化和多模型接入，对有数据隔离要求的企业更友好。踩坑是只看 Demo 效果，不看权限、日志、灰度、回滚、模型成本和知识库维护，这些才决定能不能长期跑。从 LangChain 迁到 Dify 需要注意什么？不要直接把代码里的每个链路节点一比一搬进 Dify，应该先拆清楚哪些是提示词流程，哪些是业务逻辑，哪些是系统集成。提示词、检索和简单工具调用可以放到 Dify 工作流里，强校验、订单状态变更、支付等关键逻辑应保留在后端服务，通过 API 工具让 Dify 调用。配置上要补模型供应商、知识库分段策略、环境变量、API Key、日志查看权限和测试数据集。最大的坑是迁移后缺少回归测试，建议保留一组标准问题，对比准确率、响应时间和单次成本，再决定是否切生产流量。

Dify 的监控和日志主要用来回答三个问题：应用有没有被正常调用、慢在哪里、钱花在了哪里。面试里不要只背“有调用统计、对话日志、Token 统计”，更要说清楚怎么用这些数据定位问题。一般先看应用层监控里的请求量、成功率、平均响应时间和 Token 消耗，再回到具体会话日志检查用户输入、模型输出、上下文长度、工作流节点耗时和错误信息。真正做优化时，监控看趋势，日志看现场，成本统计看取舍，三者要一起看。追问Dify 里哪些指标最值得优先看？优先看请求量、错误率、响应时间和 Token 用量，因为它们分别对应稳定性、体验和成本。平均响应时间只能看大概，排查体验问题时更建议看 P95 或 P99，慢请求往往藏在长尾里。Token 用量不能只看总数，还要拆成输入和输出，输入过大通常说明知识库召回、历史上下文或提示词模板太臃肿。这里的取舍是，监控指标越细越利于定位，但也会增加解释成本，团队初期先固定 4 到 6 个核心指标更稳。发现 Dify 应用变慢时应该怎么排查？先确认是不是所有请求都慢，如果只有部分用户或部分问题慢，就从对话日志里找对应会话。然后看工作流节点耗时，区分是模型响应慢、知识库检索慢、HTTP 工具调用慢，还是提示词和上下文太长。常见踩坑是只盯模型供应商，结果真正耗时在外部 API 超时或知识库召回过多。边界也要说清：Dify 能帮你看到应用链路和日志，但底层模型排队、网络抖动、数据库慢查询仍需要结合部署环境的 Prometheus、容器日志或云监控一起看。如何通过日志优化 Token 成本？先抽样查看高 Token 会话，判断输入长是因为系统提示词过长、历史消息保留太多，还是知识库片段召回过宽。优化时可以缩短提示词模板、限制上下文轮数、调整知识库 top_k、提高相似度阈值，并控制输出长度。取舍在于，压缩上下文能省钱也能变快，但过度压缩会让模型丢失关键信息，回答质量会下降。比较稳的做法是先在测试应用里做 A/B 对比，看成功率、人工满意度和单次成本是否同时改善。Dify 日志能不能直接当审计日志使用？不建议完全等同。对话日志适合分析输入输出、排查异常和复现问题，但企业审计还需要记录谁在什么时间修改了应用、模型配置、知识库和 API Key。涉及隐私数据时，还要考虑日志脱敏、保存周期和访问权限，不能让所有编辑者随便查看用户原始输入。一个常见坑是把生产用户问题直接导出给外部人员分析，里面可能包含手机号、合同内容或内部系统字段。企业里通常要把 Dify 日志和网关日志、身份系统、SIEM 或集中日志平台对接，才能满足完整审计要求。私有化部署时需要补哪些监控配置？私有化部署不能只依赖 Dify 页面里的应用统计，还要补容器、队列、数据库、Redis、对象存储和模型网关的监控。操作上至少要采集服务存活、CPU、内存、磁盘、接口耗时、错误日志，并设置告警阈值，例如错误率连续 5 分钟升高、队列积压、数据库连接耗尽。日志最好集中到 ELK、Loki 或云日志服务，方便按 requestid、appid、user_id 串联一次请求。边界是 Dify 自身能暴露应用视角，但平台级容量规划仍要靠基础设施监控，否则页面看起来只是“应用慢”，实际可能是宿主机磁盘打满。

Dify 插件系统的作用，是把模型、工具、数据源和外部服务封装成可安装、可配置、可复用的能力，而不是把所有逻辑写死在某个工作流节点里。对开发者来说，插件至少包含三件事：声明自己提供什么能力，定义用户需要填写哪些参数，在运行时代码里执行调用并返回结构化结果。这样同一个搜索、工单、数据库或消息推送能力，可以被多个应用复用。插件由清单、定义和运行时代码组成插件清单描述名称、版本、作者、图标、权限和配置项；工具定义描述参数类型、是否必填、前端如何展示；运行时代码负责调用外部 API、处理文件或返回模型结果。以工具插件为例，如果要接入内部工单系统，可以把“查询工单”“创建工单”“追加评论”拆成不同工具，而不是让每个工作流都手写 HTTP 请求。identity: name: ticket_query author: platform-team label: zh_Hans: 查询工单parameters: - name: ticket_id type: string required: true label: zh_Hans: 工单 ID运行时代码要处理异常和敏感字段插件调用外部服务时，不能把所有失败都包装成“系统错误”。参数缺失、鉴权失败、限流、超时、业务数据不存在，对用户的提示和重试策略都不一样。返回结果也要裁剪，模型只需要完成任务所需字段，不应该拿到 token、手机号、内部备注等敏感信息。from dify_plugin import Toolclass TicketQueryTool(Tool): def _invoke(self, tool_parameters): ticket_id = tool_parameters.get("ticket_id") if not ticket_id: yield self.create_text_message("ticket_id 不能为空") return data = self.session.get(f"/tickets/{ticket_id}", timeout=8).json() yield self.create_json_message({ "id": data["id"], "status": data["status"], "summary": data.get("summary", "") })使用插件要控制权限和耗时能查客户资料、发消息、执行 SQL 的插件，本质上都是可被模型间接触发的操作入口。凭证要放在平台安全配置里，scope 尽量小，高风险动作最好增加人工确认。性能上也要设置超时、缓存和输入大小限制；几分钟的离线任务不适合同步插件调用，否则用户体验和排错都会很差。插件发布前还要准备最小可用示例和失败样例。前者帮助使用者快速验证凭证和参数，后者能说明哪些错误需要用户处理、哪些应该找平台排查。没有这些样例，插件一旦进入多个工作流，维护者很难判断问题来自配置、外部 API 还是插件代码。插件版本升级时也要说明兼容性，尤其是参数名、返回字段和权限 scope 的变化。否则旧工作流可能还能运行，但模型收到的数据结构已经变了。追问Dify 插件和普通工作流节点有什么区别？普通节点更像一次具体编排，插件是可复用能力封装。插件能统一鉴权、参数校验、错误处理和返回格式，适合多个应用复用。取舍是一次性小需求用 HTTP 节点更快，长期能力或敏感凭证更适合做插件。工具插件、模型插件、数据源插件怎么选？调用外部 API 或执行动作，通常做工具插件。接入新的 LLM、Embedding 或重排序服务，应做模型插件；接入外部知识库、文档系统或数据库检索，更适合数据源插件。边界是不要用工具插件硬模拟模型，也不要让数据源插件承担复杂写操作。插件凭证应该怎么管理？凭证不要写进代码、提示词或工作流变量，应放在插件配置或平台安全存储中。多租户环境还要区分 workspace 级和用户级凭证。踩坑最多的是把测试 token 打进插件包，发布后所有环境都误用同一份凭证。插件返回给模型的数据要裁剪吗？要裁剪。返回太多会浪费 token，也可能暴露敏感信息；模型通常只需要状态、摘要、原因和可追踪 ID。边界是不能裁剪到不可解释，否则用户和开发者都不知道插件为什么给出这个结果。

Pod 是 Kubernetes 里最小的可调度单元，不是容器本身。一个 Pod 可以包含一个或多个容器，这些容器共享网络命名空间、存储卷和生命周期，被调度到同一个节点上运行。大多数业务场景是一个 Pod 一个主容器；只有当多个容器必须紧密协作、共享 localhost 或共享文件时，才适合放进同一个 Pod。理解 Pod 的重点是：它是一次运行实例，天然会被替换，不应该把它当成固定机器来使用。Pod 和容器是什么关系容器负责运行进程，Pod 负责把一组容器包装成 Kubernetes 能调度和管理的对象。同一个 Pod 内的容器共享同一个 IP，可以通过 localhost 通信，也可以挂载同一个 volume 交换文件。取舍是协作方便，但扩缩容粒度也被绑在一起：一个 Sidecar 占用资源过高，会影响主容器；主容器需要扩容时，Sidecar 也会跟着复制。不要把数据库、后端、前端这类生命周期不同的组件塞进一个 Pod。apiVersion: v1kind: Podmetadata: name: web labels: app: webspec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: memory: 256MiPod 生命周期有哪些阶段Pod 常见 phase 有 Pending、Running、Succeeded、Failed 和 Unknown。Pending 表示对象已经创建，但还没成功运行，原因可能是调度失败、镜像拉取慢、PVC 没绑定或 init container 还没完成。Running 只表示 Pod 已经绑定节点并且至少一个容器在运行，不等于业务已可接流量。Succeeded 和 Failed 常见于 Job，Unknown 多和节点失联或 kubelet 状态无法上报有关。kubectl get pod web -o widekubectl describe pod webkubectl get events --sort-by=.metadata.creationTimestamp重启策略怎么选Pod 的 restartPolicy 有 Always、OnFailure、Never。Deployment、DaemonSet、StatefulSet 这类长期服务通常只能用 Always，因为控制器期望服务持续运行。Job 常用 OnFailure，失败时让容器重跑，成功退出就不再重启。Never 适合一次性调试或希望失败状态被保留下来的任务。边界是 restartPolicy 只管 Pod 内容器重启，不等于控制器是否会重新创建 Pod；Deployment 即使容器一直崩，ReplicaSet 仍会努力维持副本数。apiVersion: batch/v1kind: Jobmetadata: name: data-migratespec: template: spec: restartPolicy: OnFailure containers: - name: migrate image: busybox command: ["sh", "-c", "./migrate.sh"] backoffLimit: 3探针和生命周期钩子别混淆livenessProbe 用来判断容器是否需要重启，readinessProbe 用来判断 Pod 是否可以加入 Service 后端，startupProbe 用来保护启动慢的应用。常见踩坑是把 readiness 写得太宽，应用还没连上数据库就接流量；或者把 liveness 写得太激进，启动高峰时被反复杀掉。生命周期钩子如 preStop 更适合优雅下线，让应用先停止接新请求，再等待连接处理完。readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10为什么不建议直接管理裸 Pod裸 Pod 删除后不会自动恢复，节点故障时也缺少更高层控制器帮你维持副本。生产服务通常应该用 Deployment、StatefulSet、DaemonSet 或 Job 创建 Pod。Deployment 适合无状态服务，StatefulSet 适合有稳定身份和存储的服务，DaemonSet 适合每个节点一个代理，Job 适合一次性任务。直接写 Pod YAML 可以用于学习和临时排查，但不适合作为长期交付方式。追问Pod 为什么不是直接等于容器？Kubernetes 需要一个比容器更高的抽象来表达共享网络、共享卷、调度和生命周期。Pod 内多个容器可以通过 localhost 通信，这对 Sidecar、日志代理、服务网格代理很有用。取舍是这些容器会被一起调度、一起扩缩容，不能独立水平扩展。只有强协作关系才放同一个 Pod，否则应该拆成不同工作负载。Pending 一定是镜像拉不下来吗？不一定。Pending 可能是调度阶段就失败了，比如资源 request 太高、节点污点没有容忍、亲和性规则过硬、PVC 未绑定，也可能是镜像拉取或 init container 阶段卡住。最可靠的方式是看 kubectl describe pod 里的 Events。踩坑点是只看 Pod phase 会误导判断，真正原因通常写在 Warning 事件里。Running 是否代表服务已经可用？不代表。Running 只说明容器层面已启动，业务可能还在加载配置、连接数据库或预热缓存。Service 是否转发流量主要看 readinessProbe 和 EndpointSlice，而不是只看 Pod phase。边界是没配置 readinessProbe 时，Kubernetes 可能过早把 Pod 加入后端。滚动发布中这会导致短暂 502 或请求超时。Always、OnFailure、Never 应该怎么选？长期服务用 Always，失败了就重启，配合 Deployment 等控制器维持副本。批处理任务通常用 OnFailure，让非零退出码触发重试，成功退出后保持完成状态。Never 适合调试或希望失败现场保留下来的任务。不要在 Deployment 里幻想用 OnFailure 管服务生命周期，这不符合控制器约束，也会让行为变得难以预测。Pod 被删除后数据会不会还在？要看数据放在哪里。容器文件系统和 emptyDir 通常会随 Pod 消失，PVC 挂载的持久卷则可以跨 Pod 保留。取舍是持久化能保护数据，但也引入存储绑定、访问模式、扩容和回收策略问题。生产里不要把重要数据写在容器本地路径，除非明确接受 Pod 重建后数据丢失。

Kubernetes Service 的作用，是给一组会变化的 Pod 提供一个稳定访问入口。Pod IP 会随着重建、扩缩容、滚动发布而变化，客户端如果直接访问 Pod，很快就会遇到地址失效和负载不均的问题。Service 用 selector 找到后端 Pod，通过 EndpointSlice 记录真实后端，再由 kube-proxy 或 CNI 数据面把流量转发过去。理解 Service 的关键不是背类型，而是知道不同类型解决的是“集群内访问、节点端口暴露、云负载均衡、外部域名映射”这几类问题。Service 如何找到后端 Pod最常见的 Service 通过 selector 匹配 Pod 标签。只要 Pod 上有 app: web，它就会被加入 Service 对应的 EndpointSlice。Deployment 滚动更新时，新旧 Pod 会动态进出后端列表，Service 的 ClusterIP 和 DNS 名称保持不变。踩坑点是 selector 写错时 Service 仍然存在，但没有后端，访问表现通常是连接失败或超时。apiVersion: v1kind: Servicemetadata: name: webspec: type: ClusterIP selector: app: web ports: - name: http port: 80 targetPort: 8080---apiVersion: apps/v1kind: Deploymentmetadata: name: webspec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: web image: nginx ports: - containerPort: 8080kubectl get svc webkubectl get endpointslice -l kubernetes.io/service-name=webkubectl describe svc web四种 Service 类型怎么选ClusterIP 是默认类型，只能在集群内部访问，适合微服务之间互调、内部数据库代理、队列服务等。它安全、简单，也最常用。边界是集群外不能直接访问，除非配合 Ingress、Gateway、端口转发或 VPN。NodePort 会在每个节点上打开一个端口，外部可以通过 NodeIP:NodePort 访问。它适合临时测试、裸金属环境接入外部负载均衡器，默认端口范围通常是 30000-32767。取舍是暴露面更大，而且节点 IP 变化、端口冲突、安全组放行都要自己管，生产 HTTP 服务一般不直接把 NodePort 当最终入口。LoadBalancer 会请求云厂商创建外部负载均衡器，再把流量转到 Service 后端。它适合云上对外暴露 TCP/UDP 服务，使用体验最好。边界是依赖 cloud-controller-manager 和云平台权限，裸金属集群默认不会自动得到外部 LB，通常要配 MetalLB 或云厂商插件。ExternalName 不代理流量，只返回一个 CNAME，把集群内服务名映射到外部 DNS 名称。它适合把外部数据库、第三方 API 用统一的集群内域名表达出来。踩坑点是它没有 ClusterIP，也没有端口转发和健康检查能力，排障时不要去找 Endpoint。apiVersion: v1kind: Servicemetadata: name: external-dbspec: type: ExternalName externalName: db.example.comkube-proxy 在中间做什么kube-proxy 监听 Service 和 EndpointSlice 变化，在节点上维护转发规则。iptables 模式简单稳定，但规则很多时更新成本会上升；IPVS 模式适合更大规模，支持更丰富的负载均衡算法。现在不少 CNI 也会用 eBPF 接管 Service 数据面，这时 kube-proxy 可能被替代。边界要看集群实现，不能只凭“Service 不通”就断定 kube-proxy 有问题。Headless Service 适合什么场景Headless Service 设置 clusterIP: None，不会分配虚拟 IP，而是让 DNS 直接返回后端 Pod 地址。它常用于 StatefulSet，比如数据库、消息队列这类需要稳定 Pod 身份的应用。取舍是客户端要能处理多个后端地址和连接策略，不能再完全依赖 Service 做统一负载均衡。apiVersion: v1kind: Servicemetadata: name: mysqlspec: clusterIP: None selector: app: mysql ports: - port: 3306追问ClusterIP、NodePort、LoadBalancer 的关系是什么？LoadBalancer 通常会包含 NodePort，NodePort 又建立在 ClusterIP 之上，所以它们不是完全割裂的三套机制。ClusterIP 解决集群内稳定访问，NodePort 把入口扩到节点端口，LoadBalancer 再借助云厂商或外部 LB 提供公网或内网入口。取舍是越往外暴露，运维边界越大，安全组、证书、源地址保留和费用都要考虑。内部服务不要为了“方便”直接用 LoadBalancer。Service selector 写错会发生什么？Service 对象会创建成功，DNS 也可能正常解析，但 EndpointSlice 为空。客户端访问时通常表现为连接被拒绝、超时或没有可用后端。排查时先执行 kubectl get endpointslice -l kubernetes.io/service-name=<svc>，再核对 Pod 标签和 Service selector。这个坑很常见，因为 YAML 校验不会知道你的业务标签是否写对。什么时候用 Ingress，而不是直接用 LoadBalancer？如果是 HTTP/HTTPS，多服务共享域名、路径路由、TLS 证书和灰度规则，用 Ingress 或 Gateway API 通常更合适。每个 Service 都建一个 LoadBalancer 简单直接，但成本高、入口分散，也不好统一做证书和访问控制。边界是非 HTTP 协议不一定适合 Ingress，需要看控制器是否支持 TCP/UDP 转发。生产里常见做法是一个 Ingress Controller 前面挂一个 LoadBalancer。sessionAffinity 能解决所有会话保持问题吗？不能。sessionAffinity: ClientIP 只能按客户端 IP 做相对简单的粘性会话，NAT、代理和移动网络会让多个用户看起来来自同一个 IP。它也不理解应用层登录态，Pod 重启后会话仍可能丢失。更稳的做法是把会话放到 Redis、数据库或外部状态存储里。Service 层会话保持可以作为补充，不应该成为唯一依赖。Service 不通时优先排查哪几步？先查 Service 是否有 ClusterIP 和端口，再查 EndpointSlice 是否有后端地址。然后进同命名空间 Pod 里用 curl 或 nc 测 Service DNS、ClusterIP 和 Pod IP，区分是 DNS、Service 转发还是应用端口问题。NodePort 或 LoadBalancer 不通时，还要检查节点安全组、云负载均衡器健康检查和 externalTrafficPolicy。不要只看 Service YAML，真正的线索通常在 EndpointSlice、事件和后端 Pod readiness。

Kubernetes 控制平面是集群的决策层，负责接收请求、保存状态、做调度决策，并不断把实际状态拉回到期望状态。它通常由 kube-apiserver、etcd、kube-scheduler、kube-controller-manager 和 cloud-controller-manager 组成。简单说，API Server 是入口，etcd 是账本，Scheduler 负责把 Pod 放到合适节点，Controller Manager 负责持续纠偏，Cloud Controller Manager 负责和云厂商资源打交道。真正排障时，不要把它们看成一组静态组件，而要看一次资源变更如何流过这些组件。控制平面的核心组件kube-apiserverkube-apiserver 是所有请求的统一入口，kubectl、控制器、调度器、Webhook 和外部系统都通过它读写集群资源。它负责认证、授权、准入控制、对象校验和 API 聚合，最后再把合法状态写入 etcd。API Server 本身是无状态组件，所以可以部署多个副本放在负载均衡器后面。边界是：它不直接创建容器，也不负责调度，只负责让状态变更有统一入口。kubectl get --raw='/readyz?verbose'kubectl get pods -n kube-system -l component=kube-apiserveretcdetcd 保存 Kubernetes 的全部关键状态，包括 Pod、Deployment、Service、Secret、ConfigMap、Node 状态和 Lease。它基于 Raft 保证一致性，常见生产部署是 3 或 5 个成员。取舍很明确：etcd 强一致带来可靠状态，但对磁盘延迟、网络抖动非常敏感。踩坑最多的是只备份了业务数据，忘了备份 etcd；一旦控制平面故障，集群对象就很难恢复。ETCDCTL_API=3 etcdctl snapshot save /backup/etcd.db \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.keykube-schedulerkube-scheduler 监听还没有绑定节点的 Pod，先过滤掉不满足资源、亲和性、污点容忍、端口、卷拓扑等条件的节点，再给剩余节点打分，最后把绑定结果写回 API Server。它不会启动 Pod，真正启动容器的是工作节点上的 kubelet。一个常见误区是以为 Pod Pending 一定是调度器坏了，实际更多是 CPU/内存 request 太高、PVC 未绑定、节点污点没容忍或亲和性规则写得过硬。kube-controller-managerkube-controller-manager 运行一组控制器，例如 Deployment、ReplicaSet、Node、Job、CronJob、EndpointSlice、ServiceAccount 等控制器。控制器的模式是 watch 资源变化，比较期望状态和实际状态，然后发起下一步变更。比如 Deployment 期望 3 个副本，实际只有 2 个，ReplicaSet 控制器会补一个 Pod；Node 长时间失联，Node Controller 会更新状态并触发后续驱逐。它的价值在“持续调和”，不是执行一次就结束。cloud-controller-managercloud-controller-manager 把云厂商相关逻辑从 Kubernetes 核心里拆出来，负责云节点生命周期、LoadBalancer、路由和云盘等资源。自建裸金属集群可能没有它，云上集群通常离不开它。边界要分清：Service type=LoadBalancer 创建不出外部负载均衡时，问题经常不在 kube-proxy，而在云控制器权限、配额、子网标签或安全组配置。apiVersion: v1kind: Servicemetadata: name: webspec: type: LoadBalancer selector: app: web ports: - port: 80 targetPort: 8080一次创建 Pod 会发生什么用户执行 kubectl apply 后，请求先到 API Server，经过认证、授权和准入控制，再写入 etcd。Scheduler 看到这个 Pod 没有 spec.nodeName，开始选择节点并写入绑定结果。目标节点上的 kubelet watch 到属于自己的 Pod 后，通过容器运行时拉镜像、创建容器、挂载卷并上报状态。控制器同时观察这些状态，如果副本数不足、节点异常或对象被删除，就继续发起新的调和动作。kubectl apply -f pod.yamlkubectl get pod demo -o widekubectl describe pod demokubectl get events --sort-by=.metadata.creationTimestamp追问API Server 为什么要设计成无状态？无状态的好处是可以水平扩展，多个 API Server 实例后面挂一个负载均衡器即可提升可用性。状态统一放在 etcd，避免每个 API Server 各自保存一份数据导致一致性问题。取舍是 API Server 对 etcd 的依赖非常强，etcd 慢了，整个集群的读写都会跟着慢。生产环境里经常把 API Server 扩了很多副本，却忽略了 etcd 磁盘延迟，这类扩容收益很有限。etcd 为什么通常部署奇数个节点？etcd 使用 Raft，多数派可用才能提交写入，所以 3 节点能容忍 1 个故障，5 节点能容忍 2 个故障。偶数节点并不会提高多数派容错能力，比如 4 节点仍只能容忍 1 个故障，反而增加同步成本。边界是成员越多写入延迟越高，不是越多越安全。小中型集群用 3 个 etcd 成员通常比盲目堆到 7 个更稳。Scheduler 和 Controller Manager 都在“控制状态”，区别是什么？Scheduler 只解决“这个未调度 Pod 放到哪个 Node”这个决策问题，核心输出是绑定关系。Controller Manager 负责更广的持续调和，比如副本数、节点状态、EndpointSlice、Job 完成情况等。踩坑点是排查 Pending Pod 时先看调度事件，排查副本补不齐时再看控制器和 ReplicaSet 事件。把两者混在一起，容易误判问题方向。控制平面高可用是不是只要多部署几个 master？不是。高可用至少要考虑 API Server 多副本、etcd 多成员、Controller Manager 和 Scheduler 的 leader election、前置负载均衡器以及证书和备份。只加 master 节点但 etcd 仍是单点，故障时集群状态照样不可写。另一个边界是多副本不等于无限可用，错误的准入 Webhook、过期证书或慢 etcd 仍可能让整个控制面卡住。控制平面异常时应该先看什么？先看 API Server 的 readyz、etcd 健康和 kube-system 里控制平面 Pod 日志，再看事件和证书有效期。不要一上来重启所有组件，尤其是 etcd 抖动时，频繁重启会放大选主和恢复时间。命令层面可以从 kubectl get --raw=/readyz?verbose、kubectl get componentstatuses（旧集群可用）和 journalctl -u kubelet 开始。能访问节点但访问不了 API Server 时，还要检查负载均衡器、6443 端口和控制平面证书。

Kubernetes 工作节点是实际运行 Pod 的机器，核心组件通常包括 kubelet、容器运行时、kube-proxy，再加上 CNI、CSI、日志和监控代理等配套组件。控制平面负责“决定应该是什么状态”，工作节点负责“把这个状态跑出来并持续汇报”。如果一个节点 NotReady，排查也通常围绕这几件事展开：kubelet 有没有连上 API Server，容器运行时能不能创建容器，网络插件是否正常，磁盘、内存、PID 是否触发压力状态。kubelet 负责什么？kubelet 是节点上的主代理，它从 API Server 获取分配到本节点的 Pod 规范，然后通过 CRI 调用 containerd 或 CRI-O 创建容器。它还负责挂载卷、执行探针、上报 Node 和 Pod 状态，并在容器异常退出时根据 restartPolicy 做处理。可以用下面的命令看 kubelet 和节点状态：kubectl describe node <node-name>journalctl -u kubelet -n 100 --no-pagercrictl ps -acrictl logs <container-id>kubelet 的边界也要说清楚：它不负责为 Pod 选择节点，那是 scheduler 的工作；它也不直接实现 Service 负载均衡，那主要由 kube-proxy 或 eBPF 数据面完成。很多人看到 Pod 起不来就重启 kubelet，但如果根因是镜像拉取失败、PVC 挂载失败或 CNI 没准备好，重启只会掩盖现场。容器运行时和 kube-proxy 各做什么？容器运行时负责真正创建容器、拉镜像、管理容器生命周期。现在主流选择是 containerd 或 CRI-O，Docker 的 dockershim 在 Kubernetes 1.24 之后已经移除；如果还用 Docker，也通常是通过额外适配层接入。kube-proxy 负责根据 Service 和 EndpointSlice 维护节点上的转发规则，常见模式有 iptables 和 IPVS，有些集群会用 Cilium 等 eBPF 方案替代它的部分职责。apiVersion: kubeproxy.config.k8s.io/v1alpha1kind: KubeProxyConfigurationmode: "ipvs"ipvs: scheduler: "rr"iptables 模式简单、兼容性好；IPVS 在大规模 Service 场景下性能和算法选择更好，但需要内核模块支持。取舍不是“哪个更高级”，而是集群规模、内核能力、运维熟悉度和网络插件支持是否匹配。追问Node Ready 由什么决定？Node Ready 主要由 kubelet 上报，背后包含 kubelet 自身健康、容器运行时可用性、网络是否就绪以及节点压力状态等信息。你可以用 kubectl describe node 看 Conditions，包括 Ready、MemoryPressure、DiskPressure、PIDPressure、NetworkUnavailable。边界是 Ready=True 只表示节点可参与调度，不代表节点上的每个 Pod 都健康；Pod 是否对外服务还要看 readinessProbe 和 Service 后端。生产排障时要把 Node 条件、Pod 事件和容器日志放在一起看。cordon 和 drain 有什么区别？cordon 只是把节点标记为不可调度，新 Pod 不会再放到这个节点，已有 Pod 不受影响。drain 会驱逐普通 Pod，常用于节点维护或下线：kubectl cordon <node-name>kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-datakubectl uncordon <node-name>取舍点在于你是否要立刻迁走工作负载；只做内核参数检查可能 cordon 就够了，重启机器或换盘通常需要 drain。踩坑是 DaemonSet 不会被 drain 删除，带本地 emptyDir 的 Pod 可能丢临时数据，所以命令参数要看清楚。kube-proxy 出问题会表现成什么？典型表现是 Pod 本身正常，但通过 Service 访问失败，或者只有部分节点访问 Service 异常。可以检查 kube-proxy 日志、Service 后端和节点转发规则：kubectl get svc,endpointslices -Akubectl logs -n kube-system -l k8s-app=kube-proxy --tail=100iptables-save | grep KUBE-SVC | head如果集群使用 IPVS，还要看 ipvsadm -Ln。边界是 DNS 解析失败不一定是 kube-proxy，CoreDNS、NetworkPolicy、CNI 路由同样可能导致服务不可达。不要一上来就删除 kube-proxy Pod，先确认是所有节点异常还是单节点异常。节点压力状态会怎样影响 Pod？MemoryPressure、DiskPressure、PIDPressure 触发后，节点可能拒绝新 Pod 调度，严重时 kubelet 会按 QoS 和驱逐阈值清理 Pod。BestEffort Pod 最容易被驱逐，Guaranteed Pod 相对更稳，但也不是绝对免死。实际取舍是给关键服务设置合理 requests/limits，同时给系统和 kubelet 预留资源。一个常见坑是日志撑爆磁盘导致 DiskPressure，应用没改一行代码，却出现镜像拉取失败、容器创建失败和 Pod 被驱逐。工作节点需要哪些日常巡检？至少要巡检 kubelet、containerd、CNI、磁盘、内存、节点证书和系统时间。常用命令包括：kubectl get nodes -o widekubectl top nodessystemctl status kubelet containerdjournalctl -u containerd -n 50 --no-pager巡检的边界是不要只看 Kubernetes 对象，底层内核、磁盘 inode、conntrack 表、时间同步都会影响节点稳定性。对于生产集群，建议把节点 NotReady、DiskPressure、kubelet 证书过期、容器运行时重启次数纳入告警。节点问题越早在系统层发现，越不容易演变成业务层故障。

PV 和 PVC 的区别可以用一句话概括：PV 是集群里真实或即将创建的存储资源，PVC 是业务在命名空间里提出的存储申请。Pod 不直接挑磁盘，而是引用 PVC；控制器再根据容量、访问模式、StorageClass、selector 等条件，把 PVC 绑定到合适的 PV。这样做的好处是把“应用要多大空间”和“底层用 EBS、NFS 还是本地盘”解耦，但代价是排障时要同时看 PVC、PV、StorageClass、Pod 事件，不能只盯一个对象。PV、PVC 和 StorageClass 怎么配合？动态供给是最常见的方式：开发者创建 PVC，指定 StorageClass，存储插件自动创建 PV。下面是一个比较典型的写法：apiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: fast-ssdprovisioner: ebs.csi.aws.comreclaimPolicy: DeletevolumeBindingMode: WaitForFirstConsumerallowVolumeExpansion: true---apiVersion: v1kind: PersistentVolumeClaimmetadata: name: data-pvcspec: accessModes: - ReadWriteOnce storageClassName: fast-ssd resources: requests: storage: 20GivolumeBindingMode: WaitForFirstConsumer 很关键，它会等 Pod 出现后再结合调度结果创建或绑定卷，避免卷先在 A 可用区创建，Pod 却被调度到 B 可用区。reclaimPolicy: Delete 适合临时环境，PVC 删除后底层卷也会被删；生产数据库通常更倾向 Retain，防止误删 PVC 直接丢数据。这个取舍没有绝对答案，关键看数据是否可再生，以及团队有没有成熟的备份和恢复流程。Pod 怎么挂载 PVC？Pod 里只引用 PVC 名称，不关心底层 PV 是谁：apiVersion: v1kind: Podmetadata: name: appspec: containers: - name: app image: nginx:1.25 volumeMounts: - name: data mountPath: /usr/share/nginx/html volumes: - name: data persistentVolumeClaim: claimName: data-pvc如果是 Deployment 多副本，要特别注意访问模式。ReadWriteOnce 通常只能被一个节点读写挂载，多个副本被调度到不同节点时可能挂载失败；需要多节点同时读写时，应选择支持 ReadWriteMany 的后端，比如 NFS、CephFS 或云厂商文件存储。别把 PVC 当成“共享目录万能解法”，有状态服务还要考虑锁、并发写入、数据一致性和备份窗口。追问静态 PV 和动态 PV 怎么选？动态 PV 适合大多数云上和标准化环境，开发者只需要申请容量，底层卷由 CSI 插件创建，运维成本低。静态 PV 适合已有存储、特殊挂载参数、本地盘或者迁移场景，管理员先创建 PV，再让 PVC 通过 storageClassName、容量和 selector 去绑定。取舍点在于灵活性和自动化：动态供给快，但受 StorageClass 能力限制；静态供给可控，但人工维护更容易出错。生产里常见做法是通用应用走动态，数据库迁移或本地高性能盘走静态。RWO、RWX、RWOP 有什么区别？RWO 是单节点读写，不等于单 Pod；同一节点上的多个 Pod 在某些场景下可能同时使用它。RWX 是多节点读写，适合共享文件，但底层必须真的支持多写，不是 YAML 写了就生效。RWOP 是单 Pod 读写，边界更严格，适合希望从 Kubernetes 层面避免两个 Pod 同时挂同一卷的场景。踩坑点是访问模式表达的是挂载能力，不保证你的应用层并发写入一定安全。为什么 PVC 一直 Pending？先看 PVC 事件和 StorageClass：kubectl describe pvc data-pvckubectl get storageclasskubectl describe storageclass fast-ssdkubectl get pv常见原因包括 storageClassName 写错、没有默认 StorageClass、CSI 插件异常、容量或访问模式没有匹配 PV。使用 WaitForFirstConsumer 时，PVC 在 Pod 创建前 Pending 是正常的，因为它要等调度器确定节点和可用区。真正的坑是 Pod 也因为其他原因 Pending，导致你误以为是存储问题；这时要同时 kubectl describe pod 看调度事件。reclaimPolicy 选 Delete 还是 Retain？Delete 的优点是干净，PVC 删除后底层存储自动释放，测试环境和可再生数据很适合。Retain 的优点是安全，误删 PVC 时底层数据还在，但需要人工清理 PV 的 claimRef、回收磁盘或重新导入。生产数据库、用户上传文件、审计数据更适合 Retain，再配合备份策略；缓存、临时索引和 CI 产物通常可以 Delete。边界是 Retain 不等于备份，它只是“不自动删”，磁盘损坏、误写入和勒索加密仍然需要快照或异地备份解决。扩容 PVC 有哪些限制？首先 StorageClass 必须设置 allowVolumeExpansion: true，底层 CSI 也要支持扩容。扩容命令很简单：kubectl patch pvc data-pvc -p '{"spec":{"resources":{"requests":{"storage":"50Gi"}}}}'kubectl describe pvc data-pvc但缩容通常不支持，文件系统在线扩容也可能依赖节点插件和文件系统类型。踩坑最多的是只看到 PVC 容量变大，却没确认容器内文件系统是否完成扩展；可以进入容器用 df -h 验证。对数据库类应用，扩容前仍建议做快照，因为存储层操作成功不代表应用层一定能平滑消化。

Kubernetes 亲和性和反亲和性，本质上是在回答“Pod 应该靠近谁、远离谁、只能去哪里”。nodeAffinity 关心节点标签，比如把需要 SSD 的服务放到 disk=ssd 的节点；podAffinity 关心已有 Pod，比如把网关和同可用区缓存放近一点；podAntiAffinity 则常用于把同一应用副本打散，避免一个节点故障带走所有实例。真正落地时不要把所有规则都写成 required，硬约束越多，调度失败的概率越高；通常是“必须满足资源和隔离，性能偏好用 preferred”。怎么用节点亲和性限制 Pod 去指定节点？节点亲和性比 nodeSelector 更灵活，支持 In、NotIn、Exists、Gt、Lt 等操作符。比如只允许 Pod 调度到带有 nodepool=ssd 的节点，并优先选择同区域节点，可以这样写：apiVersion: apps/v1kind: Deploymentmetadata: name: apispec: replicas: 2 selector: matchLabels: app: api template: metadata: labels: app: api spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nodepool operator: In values: ["ssd"] preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 preference: matchExpressions: - key: topology.kubernetes.io/zone operator: In values: ["cn-east-1a"] containers: - name: api image: nginx:1.25这里的 requiredDuringSchedulingIgnoredDuringExecution 是硬门槛，不满足就 Pending；preferredDuringSchedulingIgnoredDuringExecution 是加分项，不满足仍可调度。后半段的 IgnoredDuringExecution 很容易被误解：它表示 Pod 调度成功后，如果节点标签后来被改掉，Kubernetes 不会主动驱逐这个 Pod。这个边界很重要，亲和性解决的是“调度时放哪里”，不是“运行中持续纠偏”。如果要给节点补标签，先用命令确认标签是否稳定存在：kubectl label node node-1 nodepool=ssdkubectl get nodes -L nodepool,topology.kubernetes.io/zone不要把临时标签当成长期调度依据。比如临时给节点打 debug=true 后忘记清理，后续 Pod 可能被错误吸到这批节点上。更稳的做法是把节点池、可用区、实例规格这类由平台维护的标签作为调度依据，业务自己维护的标签则要有变更流程。追问required 和 preferred 应该怎么取舍？required 适合合规、安全、硬件能力这类不能妥协的条件，比如 GPU 任务必须上 GPU 节点，数据库实例必须上本地盘节点。preferred 适合性能优化和成本优化，比如优先同可用区、优先 SSD、优先空闲节点，但没抢到也允许服务先跑起来。踩坑最多的是把高可用诉求也全写成 required，节点数量一少、标签不齐或滚动升级时，Pod 会长时间 Pending。实际项目里建议先用 preferred 观察调度结果，再把确实不能退让的条件收紧成 required。Pod 亲和性和反亲和性常用在哪些场景？Pod 亲和性适合把强依赖、低延迟通信的组件放近，比如计算服务和本地缓存希望在同一可用区，减少跨区访问延迟。Pod 反亲和性更常见，用来把同一 Deployment 的副本分散到不同节点或不同可用区，降低单点故障影响。边界是它依赖目标 Pod 的 label，如果 label 写错或 selector 太宽，会出现“亲和到不该亲和的 Pod”的情况。生产环境里通常给业务 label 保持稳定，避免把版本号、临时灰度标签拿来做调度依据。topologyKey 选 hostname 还是 zone？kubernetes.io/hostname 表示按节点维度分散，适合防止同一个应用的多个副本落在一台机器上。topology.kubernetes.io/zone 表示按可用区维度分散，适合云上多可用区容灾，但跨区会带来网络延迟和流量成本。取舍点在于你要防的是“单机故障”还是“可用区故障”。如果副本数小于可用区数量，强制 zone 反亲和可能导致某些副本调度不上，这时 preferred 往往比 required 更稳。如何排查亲和性导致的 Pending？先看事件，调度器通常会直接告诉你哪些节点不满足规则：kubectl describe pod <pod-name>kubectl get nodes --show-labelskubectl describe node <node-name> | grep -A5 Taints如果事件里出现 didn't match Pod's node affinity，说明节点标签和 nodeAffinity 对不上；如果出现 didn't match pod affinity/anti-affinity rules，就要检查目标 Pod 的 label 和 topologyKey。另一个常见坑是污点和亲和性叠加：亲和性允许去某节点，但没有 toleration，调度器仍然不会放过去。排查时不要只盯 affinity 字段，资源不足、污点、PVC 绑定模式也可能同时参与过滤。亲和性需要和污点容忍一起用吗？需要，但两者解决的问题不同。亲和性是在“吸引”或“偏好”某些节点，污点是节点主动“拒绝”不合适的 Pod，容忍度则是 Pod 表示自己可以接受这个拒绝条件。比如专用 GPU 节点通常会打 taint，只有声明 toleration 且有 GPU nodeAffinity 的任务才能上去。边界是 toleration 不是调度目标，它只代表“允许去”，真正想让 Pod 去哪里仍要靠 nodeSelector、nodeAffinity 或资源请求。

在早期和大量存量 Kafka 集群里，ZooKeeper 负责保存和协调集群元数据：Broker 注册、Controller 选举、Topic 与分区信息、部分配置和权限数据。它不是 Kafka 的消息存储层，真正的消息仍然写在 Broker 本地日志里。ZooKeeper 更像一个一致性协调中心，帮助 Kafka 判断“谁还活着、谁来当 Controller、元数据现在是什么状态”。ZooKeeper 管哪些事Broker 启动后会连接 ZooKeeper，并在 /brokers/ids 下创建临时节点。临时节点和会话绑定，如果 Broker 宕机或网络断开超过会话超时时间，节点会消失，其他组件就能感知 Broker 不可用。这个机制让 Kafka 能快速发现集群成员变化。Controller 选举也依赖 ZooKeeper。多个 Broker 会竞争创建 /controller 节点，创建成功者成为 Controller。Controller 负责分区 leader 选举、副本状态变化、Topic 创建删除等集群级动作。ZooKeeper 在这里提供的是互斥和通知能力，避免多个 Broker 同时认为自己是控制者。/brokers/ids/1 # Broker 注册信息/controller # 当前 Controller/brokers/topics/orders # Topic 分区与副本元数据/config/topics/orders # Topic 级配置/kafka-acl/Topic/orders # ACL 信息这些路径有助于理解 ZooKeeper 的定位：它保存的是元数据和状态，不负责传输业务消息。Consumer offset 也在 ZooKeeper 吗这要看 Kafka 版本和客户端。早期 Consumer 会把 offset 写到 ZooKeeper 的 /consumers 路径下，但新版本 Kafka 默认把 offset 存到内部 topic __consumer_offsets。所以面试或排查时不能简单说“ZooKeeper 管 Consumer offset”，更准确的说法是：旧消费者协议依赖 ZooKeeper，新消费者组协调和 offset 存储主要由 Kafka 自己完成。这个细节很容易踩坑。运维老集群时，如果还有旧客户端，ZooKeeper 里可能仍能看到 consumer 路径；新集群则更多关注 Group Coordinator 和内部 topic。判断时看客户端版本和 kafka-consumer-groups.sh 查询结果，比背路径更可靠。ZooKeeper 配置要注意什么Kafka 侧至少要配置连接串和超时。生产环境不要只放一个 ZooKeeper 节点，通常使用 3 或 5 个节点组成 quorum。节点数用奇数，是为了在故障时仍能形成多数派。# server.propertieszookeeper.connect=zk1:2181,zk2:2181,zk3:2181/kafka-prodzookeeper.connection.timeout.ms=6000zookeeper.session.timeout.ms=18000# zoo.cfgtickTime=2000initLimit=10syncLimit=5dataDir=/var/lib/zookeeperclientPort=2181server.1=zk1:2888:3888server.2=zk2:2888:3888server.3=zk3:2888:3888zookeeper.session.timeout.ms 不是越短越好。太短会把短暂网络抖动误判成 Broker 下线，引发 Controller 处理分区变化；太长又会让真实故障发现变慢。生产里要结合网络质量、GC 暂停和业务可用性要求调整。KRaft 出现后 ZooKeeper 还重要吗Kafka 新版本已经引入 KRaft，用 Kafka 自己的 Raft 元数据 quorum 替代 ZooKeeper。新建集群可以优先评估 KRaft，部署和运维链路更简单。但很多公司仍有 ZooKeeper 模式的存量集群，迁移涉及版本、工具链、监控、备份和回滚方案，不是改一行配置就结束。因此 ZooKeeper 仍然是高价值知识点。理解它能帮助你排查 Controller 抖动、Broker 频繁上下线、Topic 元数据异常和老集群权限问题。追问ZooKeeper 会保存 Kafka 的消息数据吗？不会，Kafka 消息写在 Broker 的日志目录里，ZooKeeper 保存的是元数据和协调状态。把 ZooKeeper 当消息存储是常见误解，也会导致错误的备份方案。备份 ZooKeeper 只能保护部分元数据，不能恢复业务消息。真正的数据可靠性要看 topic 副本数、ISR、acks 和 Broker 磁盘。ZooKeeper 挂了 Kafka 会立刻不可用吗？如果 ZooKeeper 集群只是少数节点故障，多数派还在，Kafka 通常可以继续工作。如果 ZooKeeper quorum 整体不可用，已有 leader 分区可能还能短时间处理读写，但创建 Topic、Controller 选举、Broker 变更等元数据操作会受影响。边界在于“已有数据面”和“控制面变更”不是一回事。生产上不能因为消息还能写就忽视 ZooKeeper 故障。为什么 ZooKeeper 要部署奇数个节点？ZooKeeper 依赖多数派确认，3 个节点允许坏 1 个，5 个节点允许坏 2 个。偶数节点不会提升多数派容错能力，反而增加成本和通信开销。比如 4 个节点仍然需要 3 个形成多数，容错能力和 3 节点一样。常见取舍是中小集群用 3 个，跨机房或更高可用要求再评估 5 个。Kafka 迁到 KRaft 后就不用理解 ZooKeeper 了吗？新建 KRaft 集群确实不再依赖 ZooKeeper，但存量系统、面试和故障复盘里仍经常遇到 ZooKeeper 模式。迁移还要考虑 Kafka 版本、元数据迁移、监控指标变化和回滚路径。只知道 KRaft 的配置，不理解旧模式，很难解释老集群 Controller 抖动或 Broker 注册异常。更稳的做法是同时理解两套元数据管理方式。ZooKeeper 相关故障通常怎么排查？先看 Kafka Broker 日志里是否有 session expired、controller moved、zookeeper disconnected 等关键字。再检查 ZooKeeper 四字命令或监控指标，例如连接数、延迟、leader/follower 状态和磁盘 fsync 时间。很多问题不是 ZooKeeper 进程挂了，而是网络抖动、磁盘慢或 Broker 长 GC 导致会话过期。排查时要把 Kafka 日志、ZooKeeper 日志和节点资源放在同一时间线看。

Vite 是一个面向现代前端项目的构建工具，开发期基于浏览器原生 ESM 提供按需转换，生产期默认用 Rollup 输出优化后的静态资源。它相比 Webpack 最明显的优势是启动快、HMR 快、默认配置更贴近现代框架。但如果把 Vite 理解成“Webpack 的全面替代品”，迁移时很容易踩坑，因为两者的开发模型、插件生态和打包边界并不完全一样。Vite 快在哪里Webpack 开发服务器启动时，通常要从入口开始构建完整依赖图。项目越大，首次启动越慢。Vite 则把源码模块交给浏览器按需请求，开发服务器只在请求到某个文件时转换它。依赖部分由 esbuild 预构建，速度很快，也能把 CommonJS 依赖整理成浏览器更容易消费的 ESM。HMR 也是同样思路。Webpack 的热更新仍然围绕打包图生成补丁；Vite 只需要定位变化模块，通过 WebSocket 通知浏览器重新 import 对应模块。对于组件很多的大型后台项目，这个差异会非常明显，尤其是只改一个页面组件时。Vite 不只是快Vite 的另一个价值是默认配置少。TypeScript、CSS Modules、PostCSS、静态资源导入、环境变量、框架插件等能力开箱就能用。新项目不需要先写一大段 loader 和 plugin 配置，团队成员更容易统一开发方式。npm create vite@latest my-app -- --template react-tscd my-appnpm installnpm run dev生产构建上，Vite 使用 Rollup，因此 tree-shaking、代码分割、动态导入和库模式都有成熟支持。对常规 SPA、组件库、文档站、管理后台来说，Vite 的默认体验已经够稳。Webpack 仍然有优势的地方Webpack 的优势是可塑性和历史生态。大量老项目依赖自定义 loader、复杂 alias、Module Federation、非标准资源处理和企业内部插件，这些不是换个命令就能迁到 Vite。Webpack 对各种“历史包袱”的兼容经验更多，遇到特殊构建链时反而更省心。所以选择不是简单的“Vite 新，Webpack 旧”。如果是新项目、现代浏览器、React/Vue/Svelte 等主流框架，Vite 通常更合适。如果是多年老项目、强依赖 Webpack 插件、微前端运行时共享复杂，迁移前要先做依赖盘点。// vite.config.tsimport { defineConfig } from 'vite'import path from 'node:path'export default defineConfig({ resolve: { alias: { '@': path.resolve(__dirname, 'src') } }, define: { __APP_VERSION__: JSON.stringify(process.env.npm_package_version) }})迁移时常见坑是把 Webpack 的 process.env.X 直接搬过来。Vite 客户端环境变量默认需要 VITE_ 前缀，通过 import.meta.env 读取；如果硬要兼容旧写法，就需要显式 define。迁移时要先验证什么第一看依赖格式，尤其是 CommonJS、动态 require 和只面向 Node 的包。第二看资源导入方式，例如 svg loader、less 全局变量、mdx 或自定义文件类型。第三看构建产物，包括 chunk 大小、路由懒加载是否正常、静态资源路径是否适配 CDN。Vite 的迁移收益很高，但最好分阶段做。先让 dev server 跑起来，再处理测试、构建、预览和 CI。一次性重写全部构建链，问题会混在一起，很难判断是业务代码、依赖格式还是 Vite 配置导致的。追问Vite 一定比 Webpack 快吗？开发期大多数现代项目会更快，尤其是冷启动和局部 HMR。生产构建不一定总是数量级领先，因为 Vite 默认还是走 Rollup，复杂项目的插件和压缩也会花时间。速度还取决于依赖数量、插件质量和文件系统性能。判断时应该用自己项目的启动、保存更新、build 三组数据，而不是只看 benchmark。老 Webpack 项目适合直接迁 Vite 吗？不建议直接大爆炸迁移。老项目通常藏着 loader、全局变量、资源规则和环境变量约定，一次性替换很容易让问题堆在一起。更稳的方式是先做一个最小页面或独立包验证，再逐步迁移入口。取舍点在于：如果构建链已经严重拖慢开发，迁移值得做；如果依赖大量私有插件，维护 Webpack 可能更便宜。Vite 和 Webpack 的插件能通用吗？不能直接通用。Vite 插件接口接近 Rollup，并额外提供开发服务器相关钩子；Webpack 插件和 loader 是另一套机制。部分 Rollup 插件能在 Vite 生产构建中使用，但开发期是否可用要看插件有没有处理 ESM 请求模型。迁移时不要只找同名插件，要验证 dev 和 build 两个阶段都正常。为什么 Vite 生产环境还会打包？开发环境追求反馈速度，可以让浏览器按需加载很多模块。生产环境要控制请求数、缓存、压缩、兼容性和资源 hash，所以仍然需要打包优化。直接把源码 ESM 发布出去在小 demo 里可行，在真实业务里通常会带来首屏请求过多和缓存不可控。Vite 的取舍是开发期少打包，生产期认真打包。迁移后线上白屏一般怎么查？先看构建产物的资源路径，尤其是部署在子路径时 base 是否正确。再看动态导入 chunk 是否 404，很多白屏其实是懒加载文件路径被 CDN 或网关改坏了。然后检查环境变量和浏览器兼容目标，开发环境能跑不代表旧浏览器能执行生产代码。最后用 vite preview 复现构建产物，而不是在 dev server 里反复刷新。

Vite HMR 的核心不是“重新打一个更小的包”，而是利用浏览器原生 ESM 和开发服务器的模块图，只更新真正变化的模块。文件改动后，Vite 服务器通过 WebSocket 通知浏览器，浏览器再按新的模块 URL 拉取更新内容。如果某个模块声明自己能接受更新，页面就不刷新；如果更新无法安全接住，Vite 才会退回整页刷新。HMR 的基本链路开发服务器启动后，Vite 会维护一张模块图，记录 URL、文件路径、导入关系和被哪些模块引用。浏览器加载页面时，每个源码模块都以 ESM 方式请求，比如 /src/App.tsx、/src/main.tsx。当你保存文件，文件监听器捕获变化，Vite 找到对应模块，再判断这次更新能不能沿依赖链被某个 HMR 边界接住。浏览器和服务端之间有一条 WebSocket 连接。服务端发送的不是完整应用代码，而是类似“某个模块更新了，请重新 import 它”的消息。浏览器端 HMR runtime 收到消息后，会给模块 URL 加上时间戳，绕过浏览器缓存并重新加载。if (import.meta.hot) { import.meta.hot.accept((newModule) => { console.log('module updated', newModule) }) import.meta.hot.dispose(() => { console.log('clean side effects') })}accept 表示当前模块愿意处理自己的更新，dispose 用来清理定时器、订阅、WebSocket 连接等副作用。很多业务项目不用手写这段，是因为 React、Vue 插件已经替你处理组件级刷新。为什么 Vite 的 HMR 通常更快Webpack 这类传统打包工具在开发期也能 HMR，但它的更新建立在打包产物和依赖图补丁之上。项目大了以后，重新编译和生成补丁的成本会变高。Vite 开发期不需要先把源码合成一个大 bundle，改哪个文件通常只转换哪个文件，速度不会随着项目模块数线性变慢。这并不代表 Vite HMR 永远是几十毫秒。如果改动的是被大量模块共同依赖的基础文件，例如全局样式、路由入口、状态管理单例，更新仍然可能扩大影响范围。快的前提是模块边界清晰，框架插件能正确识别组件更新。HMR 边界和整页刷新的取舍HMR 最难的地方不是重新加载代码，而是保证状态不乱。比如 React 组件改了样式或 JSX，保留组件状态通常是好事；但如果改了 Hook 调用顺序、模块顶层副作用或全局单例，强行热替换可能比刷新更危险。Vite 的策略是尽量精确更新，但在无法确认安全时刷新页面。开发时看到页面刷新，不一定是 Vite 慢，可能是当前模块没有形成可接受的 HMR 边界。常见原因包括：模块既导出组件又导出普通运行时变量、组件外部有不可清理的副作用、插件没有覆盖该文件类型。// vite.config.tsexport default { server: { hmr: { protocol: 'ws', host: 'localhost', port: 5173 } }}在容器、远程开发机或反向代理下，HMR 失败常常不是代码问题，而是 WebSocket 地址不通。页面能打开但保存后没反应时，先看浏览器 Network 里的 WS 连接是否成功。追问HMR 和 Live Reload 有什么区别？Live Reload 通常是文件变化后刷新整个页面，简单可靠，但页面状态会丢。HMR 只替换变化模块，理论上可以保留表单输入、组件状态和当前路由。取舍在于 HMR 需要模块声明更新边界，也需要框架插件配合。遇到状态被错误保留导致调试迷惑时，手动刷新反而更可信。为什么有些修改会触发整页刷新？因为 Vite 没找到安全的 HMR 接收方，或者插件判断这次更新不适合局部替换。比如修改入口文件、环境变量、模块顶层副作用，都会让局部更新风险变高。整页刷新是保守策略，不是失败。真正要排查的是为什么某个应该局部更新的组件没有形成边界。React 或 Vue 项目为什么很少手写 import.meta.hot？框架插件已经把常见组件更新逻辑封装好了。React Fast Refresh 会判断组件签名，Vue 插件会处理 SFC 的 template、script、style 更新。业务代码手写 HMR 主要出现在自定义状态容器、插件开发、WebSocket 客户端或非组件模块里。边界是：插件只能处理它理解的模式，写法太混合时仍可能退回刷新。HMR 失效应该从哪里排查？先看浏览器控制台和 Network，确认 WebSocket 是否连上。再看终端是否捕获到文件变化，容器挂载、网络盘和 WSL 场景都可能让文件监听不稳定。然后检查模块是否有语法错误或循环依赖，因为更新模块加载失败会中断本轮 HMR。不要一开始就改 Vite 配置，先确认链路上的“文件变化、消息发送、浏览器拉取”三步是否成立。HMR 会影响生产环境吗？不会，HMR runtime 只在开发环境注入，生产构建不会依赖它。需要注意的是，HMR 让开发反馈很快，但也可能掩盖初始化流程问题，因为页面没有从零加载。涉及登录态初始化、全局缓存、首屏请求顺序时，偶尔手动刷新页面是必要的。生产问题最终还是要用 vite build 和真实构建产物验证。

Vite 在开发环境主要依赖原生 ESM、esbuild 和开发服务器，在生产环境默认使用 Rollup 打包。这个设计不是“开发一套、上线另一套”的随意拼接，而是把两个阶段最在意的目标分开处理：开发时要快启动、快更新、少等待；上线时要稳定产物、代码分割、tree-shaking、资源压缩和缓存友好。开发环境为什么不先打包传统打包工具在启动 dev server 前，通常要先分析入口、递归构建依赖图，再把一大包代码交给浏览器。项目越大，启动越慢，改一个文件也可能牵动一片模块。Vite 的思路更直接：源码模块先按浏览器原生 ESM 方式请求，浏览器需要哪个文件，开发服务器就转换哪个文件。这里 esbuild 主要做两件事。第一是依赖预构建，把 CommonJS 或多入口依赖转换成更适合浏览器加载的 ESM。第二是处理 TypeScript、JSX 等语法转换，因为 esbuild 用 Go 写，冷启动和转换速度通常明显快于纯 JavaScript 转译链。// vite.config.tsimport { defineConfig } from 'vite'import react from '@vitejs/plugin-react'export default defineConfig({ plugins: [react()], optimizeDeps: { include: ['react', 'react-dom'] }, server: { port: 5173, hmr: true }})这段配置里的 optimizeDeps 就是开发期优化依赖的入口。踩坑点在于：如果某个依赖内部动态引用很复杂，Vite 自动扫描可能漏掉它，表现为开发时偶发加载失败或 HMR 异常，这时手动 include 往往比怀疑业务代码更有效。生产环境为什么还要 Rollup生产环境关注的是最终资源质量。浏览器可以加载 ESM，但真实线上页面不能把几千个源码模块原样丢给用户，否则请求数量、缓存策略、兼容性和压缩效果都会变差。Rollup 更擅长静态分析，它能把模块合并成合理的 chunk，删除未使用导出，提取 CSS，并配合插件处理资源 hash。Vite 使用 Rollup 不是因为 esbuild 不快，而是因为“快”和“产物可控”不是同一个目标。esbuild 也能打包，但 Rollup 的插件生态、chunk 控制和库模式构建更成熟。对业务应用来说，生产构建慢一点可以接受；如果产物拆包不合理、缓存失效频繁或公共依赖重复打入多个 chunk，线上代价会更高。export default defineConfig({ build: { target: 'es2018', sourcemap: false, rollupOptions: { output: { manualChunks: { vendor: ['react', 'react-dom'] } } } }})manualChunks 不是越细越好。拆得太粗，首屏包大；拆得太细，请求和调度成本上升。常见取舍是把稳定的大依赖单独拆出来，让业务代码变更时不影响 vendor 缓存。开发和生产差异会带来什么边界Vite 的双模式很快，但也意味着开发环境不等于生产环境。开发期按需转换，生产期整体打包，所以有些问题只会在 vite build 后暴露，比如动态导入路径无法静态分析、Node API 被错误带入浏览器、CSS 顺序在打包后变化。因此团队里不能只跑 vite 就认为没问题。提交前至少跑一次 vite build，涉及路由懒加载、第三方库升级、浏览器兼容目标变化时，还应该用 vite preview 看构建产物。追问Vite 开发环境完全不用打包吗？严格说，源码部分通常不做传统意义上的全量打包，而是按浏览器请求即时转换。依赖部分会做预构建，因为很多 npm 包并不是天然适合浏览器直接按 ESM 加载。这个取舍让启动速度更快，但也带来依赖扫描边界，遇到动态 require 或条件导出时可能需要手动配置。不要把“不打包”理解成“不处理”，Vite 只是把处理时机拆开了。esbuild 这么快，为什么生产不全用它？esbuild 的优势是速度，尤其适合开发期频繁转换。生产构建还要考虑 chunk 结构、插件兼容、资源命名、CSS 提取和库模式输出，这些是 Rollup 长期积累的强项。用 esbuild 全量生产打包不是不行，但复杂项目里可控性通常不如 Rollup。实际选择时，开发体验优先速度，线上产物优先稳定和可调。开发正常但 build 失败通常查哪里？先看动态导入、环境变量和依赖格式。开发时某些代码路径可能没被浏览器请求到，生产构建会做全局静态分析，所以隐藏问题更容易暴露。常见坑是 import(path) 的 path 无法被 Rollup 推断，或把 process.env、fs 这类 Node 侧能力带进前端包。排查时不要只盯报错文件，顺着依赖链看是谁把不该进浏览器的代码引入了。如何判断要不要配置 manualChunks？小项目通常先别配，Vite 默认策略已经够用。只有当构建产物里某个 chunk 过大、公共依赖重复、或者业务发布导致大依赖缓存频繁失效时，再考虑手动拆分。配置时要看真实 bundle 分析结果，而不是凭感觉把所有库都拆出来。拆包本质是在首屏请求数和缓存命中率之间做取舍。vite preview 能代替线上验证吗？不能完全代替，但它能帮你用本地静态服务器检查生产产物。它适合发现资源路径、懒加载、路由 fallback、hash 文件引用等问题。边界在于它不等同于 CDN、网关和真实浏览器矩阵，也不会模拟线上缓存策略。上线前如果改了 base、反向代理或静态资源域名，仍然需要在接近生产的环境验证。

Vite 启动快，并不是因为它什么都不做。业务源码交给浏览器按需请求，但 npm 依赖会先做一次依赖预构建。它把 CommonJS/UMD 转成 ESM，也把零散依赖合并成较少请求。为什么需要预构建浏览器原生 ESM 不认识裸模块导入，也不能直接执行 CommonJS。Vite 会扫描入口源码，找到第三方依赖，再用 esbuild 打到缓存目录。import React from 'react'import { debounce } from 'lodash-es'如果让浏览器逐个请求某些 ESM 包内部的几百个文件，开发首屏会很慢。预构建的取舍是冷启动多做一点工作，换来后续加载更稳定。缓存在哪里预构建结果通常在 node_modules/.vite。Vite 会根据 lockfile、package.json、配置文件判断缓存能否复用。依赖没变时，第二次启动通常更快。npx vite --force--force 会强制刷新预构建缓存。升级依赖、切分支或调整别名后，如果开发环境行为很怪，先刷新缓存是有效排查手段。不要把 .vite 提交到仓库，它只是本机开发产物。include 用来补扫描盲区Vite 的扫描很快，但不是全知全能。动态导入、运行时拼接、插件生成入口，都可能让依赖第一次没被发现。页面访问到新依赖后，Vite 会重新优化并刷新页面。import { defineConfig } from 'vite'export default defineConfig({ optimizeDeps: { include: ['lodash-es', 'dayjs/plugin/utc'] }})include 适合提前加入确定会用、但扫描器可能看不到的依赖。不要把所有依赖都塞进去，预构建越多，冷启动和缓存失效时等待越明显。exclude 不是性能开关exclude 用来排除不该预构建的依赖。比如某个包必须保持源码形态给插件处理，或者预构建后模块结构出错，才适合排除。export default defineConfig({ optimizeDeps: { exclude: ['some-vite-plugin-runtime'] }})常见误区是觉得大型依赖排除后一定更快。实际上它可能产生更多浏览器请求，或者导致 CommonJS 无法直接运行。是否排除要看错误信息和模块格式，不要只看包体积。esbuildOptions 只做兼容修正预构建由 esbuild 执行，因此可以通过 optimizeDeps.esbuildOptions 做少量定制，例如 define、loader 或 esbuild 插件。export default defineConfig({ optimizeDeps: { esbuildOptions: { define: { global: 'globalThis' }, loader: { '.js': 'jsx' } } }})边界是它只面对依赖预构建，不等同于整个项目的编译配置。修依赖兼容性可以，用它替代 Babel 或框架插件就不合适。monorepo 更容易踩坑在 monorepo 里，workspace 包可能既像源码，又像依赖。Vite 对链接依赖通常会按源码处理，方便调试，但深层依赖可能没有被预构建。export default defineConfig({ optimizeDeps: { include: ['@acme/shared > lodash-es'] }, server: { fs: { allow: ['..'] } }})本地包的取舍是调试便利和启动性能。复用包最好明确输出 ESM，并写清 exports、module 和 types。追问预构建和生产打包是一回事吗？不是。预构建主要服务开发环境，让依赖能被浏览器快速加载；生产构建由 Rollup 负责，目标是输出可部署产物。踩坑点是以为 optimizeDeps 能控制生产分包，实际生产分包要看 build.rollupOptions。为什么启动后页面会自动刷新一次？通常是首次扫描没发现某个依赖，页面访问到它时才触发重新预构建。预构建完成后模块地址变化，浏览器需要刷新。可以把这个依赖加入 include，用一点冷启动时间换更稳定的开发过程。exclude 大依赖能减少时间吗？有时能，但不是通用优化。排除后浏览器可能请求更多文件，Vite 也可能做更多运行时转换。只有预构建导致兼容问题，或依赖必须保持源码给插件处理时，才适合 exclude。CommonJS 包为什么依赖预构建？浏览器不能直接执行 require 和 module.exports。Vite 用 esbuild 把 CommonJS 转成 ESM，开发环境才能加载。边界是转换不能替代 Node 运行时能力，依赖如果需要 fs、path，前端仍要换库或做 polyfill。

Vite 插件就是一个带 name 和若干钩子的对象。它和 Rollup 插件很像，因为生产构建阶段复用了 Rollup；但 Vite 还有开发服务器、HMR、HTML 转换和依赖预构建，所以写插件不能只按构建阶段思考。最小插件怎么写插件通常写成函数，方便接收选项。真正需要哪个钩子就写哪个，不要一开始就把所有钩子列满。import type { Plugin } from 'vite'export function replaceVersion(version: string): Plugin { return { name: 'replace-version', transform(code, id) { if (!id.endsWith('.ts') && !id.endsWith('.tsx')) return null return code.replace(/__APP_VERSION__/g, JSON.stringify(version)) } }}transform 很常用，也最容易拖慢项目。每个模块都可能经过它，所以一定要先过滤文件类型和范围。config 和 configResolved 怎么选config 适合补默认配置、插入别名、修改构建选项。configResolved 在最终配置确定后执行，适合读取配置、保存状态、输出调试信息，不建议再改配置。export function inspectMode(): Plugin { let isBuild = false return { name: 'inspect-mode', configResolved(config) { isBuild = config.command === 'build' }, transform(code, id) { if (isBuild && id.endsWith('.js')) return code return null } }}边界是“改配置”和“读配置”要分开。都塞进 configResolved，后续会遇到插件顺序和覆盖问题。resolveId 和 load 适合虚拟模块如果希望用户写 import data from 'virtual:xxx'，就需要 resolveId 和 load。前者声明模块由插件接管，后者返回模块代码。export function virtualBuildTime(): Plugin { const virtualId = 'virtual:build-time' const resolvedId = '\0' + virtualId return { name: 'virtual-build-time', resolveId(id) { if (id === virtualId) return resolvedId }, load(id) { if (id === resolvedId) { return `export const buildTime = ${JSON.stringify(new Date().toISOString())}` } } }}虚拟模块适合构建时间、自动路由、主题变量、Markdown 索引。内部 ID 加 \0 前缀，可以避免被当成真实文件继续解析。configureServer 和 handleHotUpdate 只服务开发configureServer 可以加中间件，适合 mock、调试端点或开发期资源服务。handleHotUpdate 用来控制文件变化后的 HMR 范围。export function mockHealth(): Plugin { return { name: 'mock-health', apply: 'serve', configureServer(server) { server.middlewares.use('/__health', (_req, res) => res.end('ok')) } }}这些能力不会出现在生产构建里。要在文档里写清楚，否则使用者可能误以为插件提供了线上接口能力。插件顺序和阶段要克制enforce: 'pre' | 'post' 控制相对顺序，apply: 'serve' | 'build' 限制运行阶段。只服务开发的插件写 apply: 'serve'，只改产物的插件写 apply: 'build'。export function devOnlyPlugin(): Plugin { return { name: 'dev-only', apply: 'serve', enforce: 'pre' }}不要滥用 pre。太早处理文件，可能抢在 Vue、React、Svelte 插件之前，把还没转换的框架文件处理坏。追问Vite 插件和 Rollup 插件能完全通用吗？不能完全通用。生产构建阶段兼容度高，开发阶段则有 dev server、HMR、HTML 入口等 Vite 专属行为。取舍是纯构建类插件尽量按 Rollup 写，开发体验类插件要使用 Vite 钩子。transform 为什么要先过滤 id？因为开发时每个请求模块都可能经过 transform，不过滤会处理大量无关文件。小项目不明显，大项目 HMR 会变慢。边界是不要一刀切排除所有依赖，有些 workspace 源码包确实需要被插件处理。什么时候该用虚拟模块？当数据没有真实源文件，或不想让业务直接读文件系统时，可以用虚拟模块。比如构建时间、路由清单、主题变量都合适。踩坑点是虚拟模块增加调试成本，所以命名和输出要稳定。handleHotUpdate 要不要精细控制？只有理解依赖关系时才精细控制。配置文件影响全局行为时，直接 full reload 往往比错误的局部 HMR 更可靠。取舍是刷新体验和正确性，插件开发里正确性优先。

Vite 配置文件不复杂，但项目变大后，真正需要管理的东西会变多：开发服务器、代理、路径别名、构建输出、CSS、环境变量、依赖预构建和插件顺序。好的配置不是把所有选项都写满，而是把开发体验和生产产物的边界分清楚。配置文件从哪里来Vite 默认识别 vite.config.js、vite.config.mjs、vite.config.ts、vite.config.cjs。现代 TypeScript 项目通常用 vite.config.ts，配合 defineConfig 能拿到类型提示。import { defineConfig } from 'vite'import react from '@vitejs/plugin-react'export default defineConfig({ plugins: [react()], server: { port: 5173, open: true }, build: { outDir: 'dist', sourcemap: false }})如果配置要根据命令变化，可以导出函数。command 区分 serve 和 build，mode 对应 development、production 或自定义模式。export default defineConfig(({ command, mode }) => ({ base: mode === 'production' ? '/app/' : '/', build: { sourcemap: command === 'serve' }}))server 只影响开发环境server 常用选项有 host、port、open、proxy、cors、https、watch。本地联调最常见的是代理，把 /api 转到后端服务，避免开发环境跨域。export default defineConfig({ server: { host: '0.0.0.0', port: 5173, proxy: { '/api': { target: 'https://api.example.com', changeOrigin: true, rewrite: p => p.replace(/^\/api/, '') } } }})边界要记住：server.proxy 不会进入生产环境。上线后的代理要交给 Nginx、网关、BFF 或后端 CORS。build 决定产物形态build.outDir 控制输出目录，assetsDir 控制资源目录，target 决定语法目标，minify 决定压缩方式。复杂分包和文件命名通常写在 rollupOptions。export default defineConfig({ build: { target: 'es2020', chunkSizeWarningLimit: 800, rollupOptions: { output: { chunkFileNames: 'assets/[name]-[hash].js', assetFileNames: 'assets/[name]-[hash][extname]' } } }})不要一看到 chunk 警告就手写大量 manualChunks。分包能改善缓存，也可能制造更多请求；先分析体积来源，再动配置更稳。路径别名要配两处Vite 的别名写在 resolve.alias，TypeScript 的编辑器和类型解析写在 tsconfig.json 的 paths。只配一边，常见结果是开发能跑但编辑器报错，或编辑器不报错但构建失败。import { fileURLToPath, URL } from 'node:url'import { defineConfig } from 'vite'export default defineConfig({ resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } }}){ "compilerOptions": { "baseUrl": ".", "paths": { "@/*": ["src/*"] } }}`ESM 配置里不要直接用 __dirname。用 fileURLToPath(new URL(..., import.meta.url)) 更稳。CSS 和 optimizeDeps 怎么放CSS 配置常用于 CSS Modules、预处理器和 PostCSS；optimizeDeps 用来处理依赖预构建的扫描盲区或兼容性问题。export default defineConfig({ css: { modules: { localsConvention: 'camelCaseOnly' }, preprocessorOptions: { scss: { additionalData: '@use "@/styles/vars.scss" as *;' } } }, optimizeDeps: { include: ['lodash-es'] }})additionalData 适合注入变量和 mixin，不适合注入会产出实际 CSS 的规则，否则每个文件都会重复生成。追问为什么配了 @ 别名，编辑器还是报错？通常是只配了 vite.config.ts，没配 tsconfig.json。Vite 管运行和构建，TypeScript 管类型和编辑器提示，它们不是同一个解析器。取舍上两份配置有重复，但显式配置最可控。server.proxy 能当线上代理吗？不能。它只在 vite dev 的开发服务器里生效，构建产物只是静态文件。线上要用 Nginx、CDN 边缘函数、网关或后端 CORS；本地正常、线上 404，多半就是把开发代理当成了生产能力。base 应该怎么配置？部署在域名根路径就用 /，部署在 /app/ 就写 /app/。同时还要同步前端路由的 basename 或 history base。只改 Vite 的 base 不改路由，刷新深层页面仍可能出问题。optimizeDeps.include 什么时候需要？当动态导入、插件生成入口或依赖扫描盲区导致开发时反复重新优化，可以把依赖加入 include。但它不是越多越好，包含太多会拖慢冷启动。先看控制台提示和缓存行为，再决定是否手动配置。

Vite 处理静态资源时，先分清两类文件：一类在 src 里被代码引用，会进入构建图；另一类放在 public，按原路径复制到输出目录。开发环境为了快，Vite 通常让浏览器直接请求资源；生产构建时，Rollup 会接管引用、加 hash、压缩或内联。src 中的图片和字体怎么加载放在 src/assets 的图片、字体、视频，只要被 JS、TS、Vue、React 组件或 CSS 引用，Vite 就能分析到它们。开发时导入结果通常是一个可访问 URL，构建后会变成带 hash 的文件名，方便长期缓存。import logoUrl from './assets/logo.png'const img = new Image()img.src = logoUrldocument.body.appendChild(img)这种方式最稳，因为 base、输出目录和文件 hash 都由 Vite 处理。不要在代码里拼 /src/assets/${name}.png，开发时可能能访问，构建后就容易失效。?url、?raw、?inline 有什么区别默认导入图片、字体等资源时，Vite 返回 URL。?raw 会把文件内容当字符串返回，适合文本模板、shader；?inline 会强制内联成 base64；?url 则显式要求返回资源地址。import fileUrl from './manual.pdf?url'import shader from './shader.glsl?raw'import icon from './icon.svg?inline'内联能少一次请求，但会让 JS 或 CSS 变大，也会让缓存粒度变粗。小 SVG 可以内联，大图片不要为了省请求硬塞进 bundle。CSS 也是模块Vite 允许直接导入 CSS，也支持 CSS Modules 和 Sass、Less 等预处理器。开发时样式会被注入并支持 HMR；生产时会提取、压缩，并根据 chunk 关系输出。import './global.css'import styles from './button.module.css'button.className = styles.primaryCSS Modules 适合组件局部样式，全局 CSS 适合 reset、主题变量和少量基础规则。不要把所有页面样式都塞进入口文件，否则异步页面拆包后仍会被全局样式影响。public 目录适合固定路径文件public 下的文件会原样复制到构建输出根目录，不会被 hash、压缩或依赖分析。站点图标、robots.txt、第三方验证文件、必须固定 URL 的下载文件适合放这里。<link rel="icon" href="/favicon.ico" /><img src="/brand/banner.png" />如果资源需要版本化缓存，就不要放 public；如果外部系统必须按固定路径访问，public 更合适。部署在子路径时要特别注意 base，根路径写死会导致线上资源 404。常用配置怎么写import { defineConfig } from 'vite'export default defineConfig({ base: '/app/', assetsInclude: ['**/*.glb'], build: { assetsInlineLimit: 4096, rollupOptions: { output: { assetFileNames: 'assets/[name]-[hash][extname]' } } }})assetsInclude 适合让 Vite 把自定义后缀当资源处理，比如 3D 模型或特殊二进制文件。如果需要读取内容并转换成代码，就应该写插件，而不是只加资源匹配。追问src/assets 和 public 应该怎么选？被组件或样式引用、希望加 hash 的资源放 src/assets。必须固定路径、给浏览器或第三方平台直接读取的文件放 public。取舍在于是否进入构建图：进入构建图更利于缓存和路径改写，不进入构建图更直接但不受 Vite 保护。assetsInlineLimit 调大是不是一定更快？不一定。调大会减少请求，但会增大 JS 或 CSS 体积，首屏解析和缓存失效成本也会增加。边界是只内联很小、稳定、首屏必用的资源，大图和复用图片通常单独输出更好。为什么生产环境图片路径变了？生产构建会给资源加 hash，并把它们复制到输出目录，这是为了长期缓存。代码只应该使用 import 得到的 URL，不要依赖开发时看到的 /src/... 地址。常见坑是接口返回源码相对路径，构建后前端无法再访问。CSS 为什么没有按源文件拆开？Vite 的 CSS 输出跟 JS chunk 关系有关，不是按目录机械拆分。同步入口样式可能合并，异步页面样式可能独立输出。取舍是请求数量和缓存粒度，排查时应看构建产物和引用链，而不是只看源文件名。

Vite 和 Webpack 的区别，不是“新工具淘汰旧工具”这么简单。Vite 开发阶段用原生 ESM 按需加载，生产阶段交给 Rollup 打包；Webpack 从一开始就围绕完整依赖图和打包体系设计。一个默认轻快，一个承载复杂工程多年积累，选择时要看项目边界。开发阶段差异最大Webpack dev server 通常要先分析入口、loader、plugin 和依赖图，项目越大，冷启动越慢。Vite 启动时先把服务器跑起来，浏览器请求哪个源码模块，再转换哪个模块；第三方依赖则通过 esbuild 预构建，减少 CommonJS 兼容和请求过多的问题。这也是 Vite HMR 通常更快的原因。它更接近局部更新，而 Webpack 往往要重新编译受影响的模块集合。对页面多、源码多、定制不重的项目，这个差距非常明显。生产构建各有优势Vite 不是全程 esbuild，生产构建默认使用 Rollup。Rollup 在 ESM tree-shaking、库模式和产物结构控制上很成熟。Webpack 的优势则是复杂 loader、Module Federation、历史插件生态和高度定制能力。export default defineConfig({ build: { target: 'es2020', rollupOptions: { output: { manualChunks: { vendor: ['react', 'react-dom'] } } } }})新项目、现代浏览器、Vue 3、React、Svelte、组件库文档和普通中后台，大多可以优先选 Vite。如果是多年老系统，依赖自定义 loader、旧浏览器兼容、私有构建平台或复杂微前端，Webpack 仍然可能是更稳的选择。迁移时别硬翻译配置迁移 Vite 最常见的坑有三类：CommonJS 和动态 require 处理不同；客户端环境变量要从 process.env 改成 import.meta.env；Webpack loader 和 Vite/Rollup 插件不是一一对应。不要把旧配置逐条翻译，很多配置在 Vite 里本来不需要。const api = import.meta.env.VITE_API_URL更稳的迁移方式是从新页面、文档站、组件预览或独立子应用开始。先验证依赖、环境变量、部署和监控链路，再决定是否扩大范围。追问Vite 一定比 Webpack 快吗？开发冷启动和 HMR 上，Vite 通常更快，尤其是现代前端项目。生产构建不一定，取决于压缩器、插件、依赖体积和分包策略。Webpack 如果用了持久化缓存和 SWC/esbuild loader，也可能表现不错。边界是不要拿空模板 benchmark 替真实项目做决定。老项目适合直接迁到 Vite 吗？不一定。老项目常有隐藏构建逻辑，比如自定义 loader、全局变量、polyfill 和特殊别名。直接迁移可能主流程正常，边缘页面或灰度环境才出问题。更稳的取舍是先迁低风险模块，再扩大范围。生产包体积谁更小？没有绝对答案。Vite 借助 Rollup 的 ESM tree-shaking，Webpack 也有 splitChunks、sideEffects 和成熟插件。包体积更多取决于依赖写法、是否按需加载、是否引入大而全的库。常见坑是换工具前不清依赖，让构建工具背锅。微前端场景选哪个？如果重度依赖 Module Federation，Webpack 仍然更成熟。Vite 也有相关插件，但在共享依赖、版本协商和遗留系统接入上要更谨慎。取舍是成熟稳定还是开发速度。核心交易系统不要为了工具升级牺牲可预测性。团队熟悉 Webpack，还值得换吗？如果启动和 HMR 已经明显拖慢效率，值得小范围试点。Vite 配置心智更轻，但团队仍要理解 ESM、Rollup 和环境变量差异。迁移成本还包括 CI、部署、监控和文档更新。不要只让一个人迁完，否则后续没人维护。

Vite 支持 TypeScript，但默认只转译，不做完整类型检查。很多人迁移后会疑惑：页面能跑，tsc --noEmit 却报错。原因是 Vite 把开发反馈速度放在前面，类型检查需要理解整个项目的类型图，如果塞进每次模块转换，HMR 会明显变慢。Vite 负责转译，不负责兜底.ts、.tsx 文件会被 esbuild 快速转成 JavaScript，类型标注会被擦除，JSX 和新语法也会被处理。但 esbuild 不会像 TypeScript 编译器那样做完整类型分析，所以“Vite 能运行”不等于“类型安全”。type User = { id: number }const user: User = { id: '1' } // 需要 tsc 才能稳定拦住tsconfig 怎么配Vite 项目建议使用 moduleResolution: "bundler"，它更贴近现代打包器对 ESM、exports 和条件导出的解析方式。isolatedModules 建议打开，能提前暴露不适合单文件转译的写法。noEmit 让 TypeScript 只检查，不输出文件，避免和 Vite 构建产物混在一起。{ "compilerOptions": { "target": "ES2020", "module": "ESNext", "moduleResolution": "bundler", "strict": true, "isolatedModules": true, "noEmit": true, "skipLibCheck": true }, "include": ["src", "vite.config.ts"]}skipLibCheck 是现实取舍。业务项目开启它可以减少依赖声明文件带来的噪音和耗时；基础库、SDK 或类型要求极高的项目要谨慎，因为它可能掩盖第三方类型问题。类型检查放到哪里本地开发可以依赖编辑器提示，也可以接入 vite-plugin-checker。团队协作时，CI 必须执行 tsc --noEmit，否则有人关闭编辑器提示后，类型错误仍可能进入主干。import checker from 'vite-plugin-checker'export default defineConfig({ plugins: [checker({ typescript: true })]})路径别名要同时配置 Vite 和 TypeScript。resolve.alias 影响运行和构建，paths 影响编辑器和类型检查；只配一边，就会出现能运行但编辑器报错，或编辑器正常但构建失败。追问为什么 Vite 不直接检查类型？因为 Vite 的核心链路是按需转译模块，而完整类型检查是项目级静态分析。把它放进每次请求，会拖慢冷启动和 HMR。取舍是先获得运行反馈，再用编辑器、checker 或 CI 保证类型安全。踩坑点是把 Vite build 通过当成类型通过。vite-plugin-checker 和 tsc --noEmit 怎么选？本地想尽快看到错误，可以用 vite-plugin-checker。上线前要稳定兜底，应该跑 tsc --noEmit。插件更贴近开发体验，但大项目里也会占内存和 CPU。边界是合并门禁不要依赖某个开发者的编辑器。isolatedModules 为什么会让一些写法报错？它要求每个文件都能被独立安全转译，这和 esbuild 的工作方式一致。只导出类型却按值导入、部分 namespace 写法，都可能因此暴露问题。限制看起来烦，但能提前发现运行时会消失的类型代码。取舍是少一点 TS 写法自由，换来构建链路一致。路径别名为什么要配两份？Vite 和 TypeScript 是两个解析系统。只配 Vite，编辑器和 tsc 可能找不到模块；只配 TS，构建时可能解析失败。很多人以为是缓存问题，其实是配置源不一致。monorepo 里还要看 workspace 包的 exports 和声明文件。生产构建前还需要 ESLint 吗？需要，ESLint 和 TypeScript 关注点不同。TS 主要检查类型关系，ESLint 更擅长发现 Hook 依赖、未处理 Promise、禁用 API 和潜在逻辑问题。取舍是规则越多 CI 越慢，所以要区分阻断规则和建议规则。不要把 lint 只当格式化工具。