演示故障降级方案与许可证与依赖清单

• 对"license 完整性"的理解
• 诚实承认遗漏
• 整改与合规意识

承认漏了几个文件的 license 是真实的合规疏漏，说明"license 声明不完整"会导致这些文件的使用边界不明，尤其对第三方代码更可能引发法律风险。然后给出整改：逐个核对所有文件的来源与 license，补全缺失的声明，用 license 扫描工具（如 FOSSA、license-checker）自动检查。同时说明我理解"license 完整性是开源合规的一部分"，会把它纳入工程流程。展示"我懂合规，发现遗漏会系统补全"。

面试官问 license 漏文件，是考察你"是否重视开源合规"。license 声明不完整是真实风险。关键是要承认、用工具系统核对补全，并展示合规意识。

• 对 LGPL 许可证的理解
• 区分动态链接与静态链接
• 许可证合规意识

说明 LGPL 的动态链接是允许的，这是 LGPL 设计的核心：只要以动态链接方式使用 LGPL 库，被链接的代码可以保持自己的 license，无需开源，但 LGPL 库本身及其修改要开源。然后区分：静态链接则要求使用者能重新链接，并通常要提供可替换的库文件。同时说明我理解"动态链接是规避 LGPL 传染的常见方式"，如果能做到动态链接就合法，并会检查项目实际是动态还是静态链接。展示"我懂 LGPL 的合规边界"。

面试官问 LGPL 动态链接，是考察你"对许可证传染机制的理解"。LGPL 允许动态链接，这是它与 GPL 的关键区别。关键是要正确解释动态/静态链接的差异，体现合规意识。

• 对"fork 与 license 保留"的理解
• 诚实承认合规问题
• 整改意识

承认 fork 但没保留原 license 是合规问题，说明 fork 是基于原项目的，原项目的 license 必须保留（很多开源协议要求保留版权声明和 license 文本），否则可能违反原协议。然后给出整改：追溯原项目的 license，补上版权声明和 license 文件，并说明哪些部分的版权归原作者、哪些是新增。展示"我懂 fork 的合规义务，意识到必须保留原 license"。

面试官问 fork 没保留 license，是考察你"是否理解开源衍生作品的合规义务"。fork 是衍生作品，必须保留原 license。关键是要承认并展示你会追溯补全，体现合规意识。

• 对"CDN 资源 license"的理解
• 诚实承认不明确
• 合规确认意识

承认 CDN 资源 license 不明确是真实的合规隐患，说明即使资源是外链加载的，其授权（license、使用条款）依然约束使用，尤其字体、图标库、JS 库等可能有明确或隐含的 license。然后给出整改：核实每个 CDN 资源的来源与 license，明确标注，无法确认的替换为 license 清晰的资源，或用本地打包替代。展示"我理解 CDN 资源同样受 license 约束，会核实并明确"。

面试官问 CDN 资源 license，是考察你"是否理解外链资源也有合规约束"。CDN 资源 license 不明确是常见隐患。关键是要认识到需要核实并明确，而非"外链就没事"。

• 对"license 兼容性"的理解
• 识别冲突风险
• 处理策略

承认 MIT 和 GPL 混用存在 license 兼容性风险，说明 GPL 是强 copyleft，若 GPL 代码和 MIT 代码在同一个作品里编译/链接，可能使整个作品被 GPL 传染，从而与 MIT 的宽松条款冲突。然后给出处理：先明确各代码的边界，若 GPL 代码独立成进程/库，可通过隔离减少传染；若无法隔离，则可能需调整 GPL 依赖为兼容的库，或重新评估整个项目的 license。展示"我理解 copyleft 传染机制，会按边界处理冲突"。

面试官问 license 冲突，是考察你"是否理解 copyleft 传染机制"。MIT 与 GPL 混用是典型的兼容性问题。关键是要理解"传染"边界，并给出隔离或替换的处理策略。

• 面对"当场崩溃"的应变
• 是否有降级/替代方案
• 演示准备意识

不慌，先快速判断崩溃原因（前端还是后端、是否是网络/环境问题），并尝试恢复。同时说明我准备了替代方案：本地副本、录屏、截图、离线 demo，可以立刻顶上继续展示。诚实说明"线上 demo 崩溃是演示可用性的失职"，我会提前准备"多级降级"（线上→本地→录屏）。重点是"当场能切换到备用演示，而不是手足无措"。

面试官问 demo 当场崩溃，是考察"演示稳定性与应变能力"。崩溃难以完全避免，关键是是否有"降级路径"（本地演示、录屏）。展示你能快速切换备用展示，比辩解更有价值。

• 对"响应式设计"的理解
• 诚实承认兼容问题
• 补救方案

承认 layout 乱掉说明响应式/兼容性处理不足，可能因为浏览器宽度、分辨率、或字体/样式差异导致。然后说明补救：提供截图或录屏展示预期效果，并说明我会修复响应式问题（用相对单位、媒体查询、跨浏览器测试）。同时展示对"为何会乱"的理解，说明这是设计时没充分测试不同环境导致的。关键是以"能展示效果"为先，同时承认并给出修复方案。

面试官问 demo layout 乱掉，是考察你"是否理解响应式与浏览器兼容"。乱掉通常是未做跨环境测试。关键是先保证能看到效果（截图/录屏），再诚实承认并给出修复。

• 对"mock 与真实"差异的理解
• 能否描述真实场景
• 诚实与深度

承认 demo 数据是 mock 的，但说明我能讲清楚"真实场景"是什么样：真实数据有什么特征（规模、分布、脏数据、并发）、真实业务会有什么挑战、我的设计如何应对。然后区分"我验证过真实的部分"和"还没验证的部分"，并说明如何用真实数据/压测补齐。展示"我虽然用 mock 演示，但想清楚了真实场景的差异与应对"。

面试官问真实场景，是考察你"是否理解 mock 与真实的差距"。关键不是简单承认 mock，而是展示你对"真实场景"有清晰认知，能讲出差异与应对，体现深度。

• 对"硬件依赖"演示的理解
• 提供降级展示方案
• 应变能力

承认 3D demo 依赖 GPU，面试官显卡不支持是环境限制，不是 demo 本身的问题。然后提供替代：用录屏/视频展示 3D 效果、用截图展示关键帧、或提供一个低配的降级渲染模式（如软件渲染、降低画质）。同时说明"我理解 demo 要考虑观众环境，会为不同硬件准备降级方案"。展示"我能在受限环境下依然展示效果"。

面试官问 3D demo 显卡不行，是考察"演示的硬件兼容与降级能力"。3D 依赖 GPU 是客观限制，关键是提供录屏/截图/软件渲染等降级方案，而非执着于"实机跑"。

• 对"浏览器兼容性"的理解
• 提供降级方案
• 兼容性测试意识

承认 WebGL/Canvas 在旧浏览器或特定环境可能不支持，说明这是真实的兼容性考量。然后给出方案：一是特性检测（feature detection）并提供降级提示或有替代渲染；二是说明现代浏览器普遍支持，但我也理解要兼容更广的环境；三是提供截图/录屏作为兜底。展示"我理解 WebGL/Canvas 的兼容性边界，会做特性检测和降级"。

面试官问 WebGL/Canvas 兼容性，是考察你"是否想到不同浏览器环境"。关键是要展示特性检测与降级方案，而非假设"大家都用最新浏览器"。

• 对"渐进增强/降级"的理解
• 处理新旧 API 差异
• 兼容策略

说明用过时 API 可能是为了兼容旧环境，但用最新浏览器测试确实可能暴露问题。然后给出兼容策略：用特性检测判断 API 是否可用，用 polyfill 填补缺失，或做渐进增强（基础体验 + 高级体验）。同时说明我理解"新旧 API 的差异"以及"如何让代码在多变环境中稳定运行"。诚实评估是否真需要过时 API，若不需要则升级。展示"我懂跨版本兼容策略"。

面试官问用旧 API，是考察你"是否理解浏览器 API 的演进与兼容"。关键是要展示特性检测、polyfill、渐进增强等兼容策略，而非纠结"用旧的还是新的"。

• 对"硬件依赖演示"的处理
• 提供视频替代
• 应变能力

承认 demo 依赖特殊硬件（手机/VR）是客观条件，面试官没有设备时，实机演示不可行。然后提供替代：录制好的演示视频、关键操作截图、以及串讲"在真实设备上体验到的效果"。同时说明我理解"依赖硬件的 demo 需要备好视频等替代展示"，避免现场无设备就哑火。展示"我能用视频等替代方式完整传达效果"。

面试官问硬件依赖演示，是考察"演示的降级准备"。特殊硬件是客观限制，关键是提前备好视频/截图等替代展示，避免现场无设备。

• 对"加载性能"的理解
• 能否给出优化方案
• 性能优化意识

承认 10 秒加载很慢会严重损害体验，说明这通常是资源体积大、请求多、未做缓存/懒加载等导致的。然后给出优化方案：压缩资源、减少请求数、用 CDN、懒加载、缓存、优化首屏。同时说明"加载性能是产品体验的一部分"，并承认我理解慢带来的用户流失。诚实分析慢的原因，并展示优化思路。若现场可以，说明我已采取了哪些优化。

面试官问加载慢，是考察你"是否理解并重视性能优化"。10 秒加载是明显的性能问题。关键是要能分析慢的原因并给出可落地的优化方案。

• 对"资源可访问性"的理解
• 提供离线/降级方案
• 应变能力

承认依赖 CDN 在断网环境下会导致资源加载失败，说明这是"静态资源可用性"的脆弱点。然后提供替代：本地打包资源（不依赖外网）、提供离线版本、或现场说明哪些资源无法加载并口头讲解。同时说明我理解"demo 应能在受限环境下运行"，会把关键资源本地化。展示"我能处理断网情况，保证演示不中断"。

面试官问 CDN 断网，是考察"演示的环境鲁棒性"。依赖 CDN 会让断网时哑火。关键是要展示"关键资源本地化 + 降级"，而不是执着于外网加载。

• 对"HTTPS 要求"与环境的理解
• 提供兼容方案
• 应变能力

说明 demo 要求 HTTPS 通常是因为安全特性（如 secure cookie、Service Worker、某些 API 需要安全上下文），这是合理的，但承认与非 HTTPS 环境不兼容是真实问题。然后提供替代：一是说明可以在本地用 http 或 localhost 跑（localhost 通常被视为安全上下文）；二是如果必须 HTTPS，提供本地证书或说明环境限制。展示"我理解 HTTPS 的必要性，也知道如何在受限环境降级演示"。

面试官问 HTTPS 兼容，是考察你"是否理解安全上下文限制"以及"能否提供演示降级"。HTTPS 是安全需要，但也要能应对 HTTP 环境。关键是理解 localhost 例外并提供替代。

• 对"访问控制"与部署的理解
• 提供可访问方案
• 应变能力

承认云端有 IP 限制导致面试官访问不到，说明这是部署时"只考虑了自己访问"的失察。然后提供替代：一是临时开放访问或加白名单；二是提供本地运行版本；三是提供录屏/截图。同时说明我理解"部署要考虑受众的可访问性"，会为演示环境准备宽松的访问策略。展示"我能快速解决访问问题，保证演示进行"。

面试官问 IP 限制访问不到，是考察"演示的可访问性准备"。云部署带 IP 限制会让对方无法访问。关键是要能快速改为可访问，并提供本地/录屏兜底。

• 对"内网访问"限制的理解
• 提供替代方案
• 应变能力

承认 demo 部署在内网、需要 VPN 才能访问，导致外网面试官看不到，这是"演示环境与外网隔离"的失察。然后提供替代：一是把 demo 部署到公网可访问的地址；二是提供本地运行版本；三是用录屏/截图展示。说明"我理解演示要面向外部受众，应为外网准备可访问的部署"。展示"我能快速让演示可访问"。

面试官问需要 VPN，是考察"演示的外网可访问性"。内网部署会阻碍外部演示。关键是要提供公网部署或本地/录屏替代，而非"你连不上就没办法"。

• 对"演示可用性"的准备
• 提供访客/免登录方案
• 准备工作

承认需要登录的 demo 若没有访客账户，会阻碍面试官体验。然后说明提前准备：提供访客账户（预置账号密码）、提供免登录的演示模式、或提供实时演示账号。同时说明我理解"演示要降低使用门槛，不能让对方卡在登录",并会提前准备好可直接使用的账户和说明。展示"我提前想到并准备了访客入口"。

面试官问没账号，是考察"演示的准备工作是否周到"。需要登录的 demo 若没准备访客账户是明显疏漏。关键是要提前备好访客/免登录入口，降低演示门槛。

• 对"移动端演示"的理解
• 提供设备模拟/替代方案
• 应变能力

承认 H5 在 PC 上打开无法完整体现移动端效果，说明这是"演示环境与目标设备不符"的问题。然后提供替代：用浏览器开发者工具切换设备模拟模式、用手机录屏展示、或用视口模拟。同时说明我理解"移动 demo 要用移动端方式展示"，会提前准备移动模拟或录屏。展示"我能让面试官在 PC 上看到移动效果"。

面试官问移动端 H5 在 PC 上看，是考察"演示的设备适配"。移动端 demo 在 PC 上需要设备模拟或录屏。关键是要提供模拟/录屏替代，而非"就是移动端"。

• 对"CLI 与 UI"选择的理解
• 提供可视化替代
• 工程化意识

说明项目本身是 CLI 工具，CLI 是它的合理形态（可脚本化、可自动化、适合服务端），但不能因此拒绝"看 UI"的诉求。然后提供替代：录制 asciinema/命令行演示、展示输出截图、或提供一个简单的 Web 包装层。同时说明我理解"工程化"不等于"必须有 UI"，CLI 的工程化体现在可测试、可维护、可扩展，但我也愿意为演示补可视化入口。展示"我既懂 CLI 的价值，也能满足看 UI 的诉求"。

面试官问 CLI 想看 UI，是考察"你能否理解并满足对方诉求"。CLI 是合理选择，但演示要兼顾观众。关键是要提供可视化替代，并说明 CLI 的工程化价值。

• 对"依赖重量"与可运行性的理解
• 提供轻量替代
• 应变能力

说明选择 Postgres 是因为它功能强大、适合生产，但承认"让面试官装 Postgres 才能跑"确实提高了门槛。然后提供替代：用 Docker 一键起 Postgres、提供 SQLite 等轻量替代的可切换配置、或提供内存数据库。同时说明我理解"demo 要降低运行门槛"，会为依赖提供轻量化的运行方式。展示"我理解选型有取舍，也会为演示降低门槛"。

面试官问为什么用重依赖，是考察"你是否考虑过运行门槛"。Postgres 是合理选择，但 demo 要可运行。关键是提供 Docker/轻量替代，并对选型有合理的解释。

• 对"LICENSE 文件维护"的理解
• 诚实面对被改
• 恢复与防护意识

承认 LICENSE 文件被人改是"仓库维护"的问题，说明这可能是权限管理不当或误操作。然后给出处理：先确认改动内容与影响，恢复正确的 LICENSE（用 git 历史找回），并说明"我需要加强仓库权限与保护"。同时说明我理解"LICENSE 应被严肃对待，不能被随意改动"，会设置 branch 保护或权限管控。展示"我懂 LICENSE 的重要性，也知道如何恢复与防护"。

面试官问 LICENSE 被改，是考察"仓库维护与权限保护意识"。LICENSE 被改是维护失职。关键是要能恢复并用权限管理防止再犯，体现工程化维护。

• 对 GPL 许可证的理解
• 区分"商用"与"代码开源"
• 许可证选择逻辑

澄清一个常见误解：GPL 并不禁止商用，商用 GPL 代码是允许的（甚至可以收费分发），义务是把衍生作品也以 GPL 开源。所以"GPL 不能商用"是误解。然后说明我选 GPL 的理由：如果我希望代码和衍生作品都保持开源、防止被闭源商用，GPL 是合适的选择；如果希望更宽松（允许闭源商用），则选 MIT/Apache。展示"我理解 GPL 的商用规则与 copyleft 义务，能按意图选 license"。

面试官问 GPL 不能商用，是考察你"是否理解 GPL 的规则"。GPL 允许商用，义务是开源衍生作品。关键是要纠正误解，并展示按意图选 license 的逻辑。

• 对"商业许可证"限制的理解
• 区分商用许可与开源
• 合规处理

说明商业许可证的库通常限制在开源项目中分发或使用，需要区分"个人使用"与"开源分发"。诚实评估：如果项目要开源，商业许可证的库可能构成障碍，需要替换为开源替代、或购买商业授权、或将该库隔离。然后说明我理解"商业许可证的合规边界"，会检查依赖是否符合开源分发要求。展示"我懂商业许可证的限制，能评估开源可行性"。

面试官问用了商业许可库能否开源，是考察"你是否理解商业许可证限制"。商业许可库通常不能随开源项目分发。关键是要能评估并给出替换/授权/隔离方案。

• 对 AGPL 特殊条款的理解
• 区分 AGPL 与 GPL
• 合规意识

说明 AGPL 是 GPL 的加强版，它专门补上了"网络服务"的漏洞：即使只是通过网络提供服务而不分发代码，AGPL 也要求向用户提供源码。所以如果项目是网络服务（SaaS）且用了 AGPL 依赖，通常确实需要把改动后的源码开放给用户。诚实评估：若项目是商业闭源 SaaS，用 AGPL 依赖会有合规风险，需谨慎评估或替换。展示"我理解 AGPL 的网络服务传染条款，会评估合规风险"。

面试官问 AGPL 网络服务，是考察你"是否理解 AGPL 与 GPL 的关键差异"。AGPL 的"网络服务也需开源"条款是它的核心。关键是要正确理解并评估合规风险。

• 对"许可证兼容性"的理解
• 区分 MIT 与 Apache2
• 合规判断

说明 MIT 和 Apache2 都是宽松（permissive）许可证，二者兼容性很好：MIT 代码可以并入 Apache2 项目，Apache2 代码也可以并入 MIT 项目，只需保留各自的版权声明和 license 文本。二者都是允许商用、允许修改、允许闭源分发的。所以混用本身没有大的冲突，关键是要保留各自的版权声明。展示"我理解宽松许可证的兼容性，知道如何保留版权信息"。

面试官问 MIT 与 Apache2 兼容，是考察你"是否理解许可证兼容性"。宽松许可证之间兼容良好。关键是要理解并正确保留版权声明，而非担心冲突。

• 对"付费依赖"演示的理解
• 提供替代方案
• 应变能力

承认付费 SaaS 依赖让演示受限于是否有可用账号/额度，说明这是真实的可运行性障碍。然后提供替代：一是提供免费试用/沙箱账号；二是用 mock/本地替代实现同样功能；三是录制演示视频。同时说明我理解"演示不能依赖付费门槛"，会为付费依赖准备可用的替代路径。展示"我能在付费依赖受限时仍完成演示"。

面试官问付费 SaaS 依赖，是考察"演示的可运行性准备"。付费依赖会阻碍演示。关键是要提供试用账号、mock 替代或视频，保证演示可进行。