原型链用一个类比理解：每个对象都带着一个「背包」（原型对象），自己没有的东西就去背包里找，背包里没有就再去背包的背包里找，直到找到或到顶（null）。1. 原型对象（prototype）：函数的属性——每个函数创建时自动带一个 prototype 对象，这个对象里有一个 constructor 指回函数本身。当你用 new 调用函数（构造函数）时，实例的背包就是这个 prototype；2. 原型链（__proto__）：对象的属性——实例.__proto__ === 构造函数.prototype。访问 obj.x 时查找顺序：obj 自身 → obj.__proto__（即构造函数的 prototype）→ 上一级的 prototype → ... → Object.prototype → null；3. 代码验证：function Foo() {}; const f = new Foo(); f.__proto__ === Foo.prototype // true；Foo.prototype.__proto__ === Object.prototype // true；Object.prototype.__proto__ === null // true。继承就是靠这条链：ES6 的 class extends 本质是原型链的语法糖（子类的 prototype.__proto__ 指向父类的 prototype，子类本身的 __proto__ 指向父类构造函数）。记忆要点：prototype 是「函数」的属性（给未来的实例用），__proto__ 是「对象」的属性（指向自己的背包）。... 展开详请

不正常，这属于前端展示 Bug 或数据映射错误。 检查数据源：确认提交时后端返回的 category 或 type 字段值确实是“专家团”（如 expert_group），还是被错误地传成了 expert。 排查前端逻辑：看确认页渲染组件是否硬编码了标签，或者字典映射表里漏配了“专家团”对应的显示文案。 快速验证：尝试用浏览器 DevTools 查看 Network 响应，如果接口给的是对的但页面显示错，就是前端问题；如果接口给的本身就是错的，那是后端序列化或入库逻辑有误。 建议直接截图发给开发团队，重点查枚举值映射和表单提交 payload。 官方详细解决方案：https://cloud.tencent.com/product/workbuddy-enterprise?Is=sdk-topnav... 展开详请

其实原理特简单，就是“骗”浏览器别急着加载。 一开始，img标签的src只放个占位图（比如灰色块），真地址存进data-src里。这样页面打开时，浏览器根本不知道后面藏着大图，自然不发请求。 然后靠JS盯着屏幕：要么用IntersectionObserver监听元素有没有进视野，要么算滚动距离。一旦图片露头或者快露头了，就把data-src的值塞给src。这时候浏览器一看：“哟，src变了”，才真正去下载那张大图。 现在新浏览器直接写loading="lazy"也能行，但老项目或需要精细控制（比如提前200px预加载）时，还是得手写JS逻辑。核心就一点：没滚到那儿，就不发请求，省流量也省速度。 官方详细解决方案：https://cloud.tencent.com/solution/image-delivery... 展开详请

别背定义，看 Network 面板最直观。 强缓存就是浏览器“装死”，根本不发请求。你看到状态码是 (from disk cache) 或 (memory cache)，时间戳为 0.00s，那就是强缓存生效了。靠 Cache-Control 或 Expires 控制，适合图片、CSS 这种几年都不变的死物。 协商缓存则是浏览器“勤快”地发请求去问服务器：“我手里这个还是最新的吗？”如果没变，服务器回个 304，浏览器继续用旧的；变了才传新数据。靠 ETag 或 Last-Modified 握手。HTML 页面必须用它，因为每次部署都可能变。 实战里，静态资源设长时效强缓存+版本号（如 app.v1.js），HTML 页面无脑走协商缓存。别纠结理论，盯着 304 和 (cache) 标签练几次就熟了。 官方详细解决方案：https://cloud.tencent.com/product/teo... 展开详请

结论：两者定位不同。Webpack 是"先打包再运行"的通用构建器，Vite 是"开发期按需编译、生产期用 Rollup 打包"的构建工具。新项目且面向现代浏览器，优先选 Vite；依赖大量历史 loader/插件或需要深度定制时，Webpack 更稳。 一、开发阶段的差异 1. Webpack：启动前要从入口递归分析依赖并打成 bundle，项目越大冷启动越慢，热更新需要重新构建受影响的模块图。 2. Vite：依赖用 esbuild 预构建（转成 ESM 并缓存），源码直接交给浏览器的原生 ESM，按请求时才转换，所以冷启动与 HMR 基本不随项目体量线性变慢。 二、生产构建的差异 1. Webpack：自带代码分割、Tree Shaking、Module Federation 等，配置灵活但复杂。 2. Vite：生产构建基于 Rollup，配置更少，默认产物体积和分包策略已较合理；可通过 build.rollupOptions 自定义。 3. 两者在生产期都需要打包，Vite 的优势主要在开发体验，不是"不打包"。 三、生态与兼容性 1. Webpack：loader/plugin 生态成熟，对 CommonJS、老浏览器、特殊资源处理的方案多。 2. Vite：插件接口兼容 Rollup 插件，Vue、React、Svelte 等都有官方模板；老浏览器需用 @vitejs/plugin-legacy。 3. 迁移老项目要检查：require 的使用、process.env 写法（Vite 用 import.meta.env）、别名与 CSS 预处理器配置。 四、怎么选 - 新项目、现代浏览器、追求开发速度：Vite。 - 老项目、微前端（Module Federation）、复杂自定义构建链路：Webpack。 - 库开发：Vite 的库模式或 Rollup 更轻量。 五、构建之后的部署（落到腾讯云） 前端构建产物都是纯静态文件，两种工具的部署方式一致： 1. 静态托管：上传到对象存储 COS，开启静态网站托管，SPA 路由需把错误文档/索引文档都指向 index.html。 2. 加速：在 COS 前接 CDN 或 EdgeOne，对带 hash 的 js/css 设置长缓存，对 index.html 设置短缓存或不缓存，避免发版后用户拿到旧入口。 3. 发布：每次发版后对 index.html 做缓存刷新（URL 刷新），带 hash 的资源无需刷新。 具体缓存规则与控制台入口以产品文档为准。... 展开详请

简单说，虚拟 DOM（VDOM）就是一棵用 JavaScript 对象模拟的 HTML 树。它不直接操作浏览器里的真实 DOM，而是先在内存里算好账，最后再一次性更新页面。 它主要解决了两个痛点： 性能瓶颈：原生 DOM 操作极慢，频繁修改会触发浏览器重排和重绘。VDOM 通过“批处理”和最小化更新，把多次操作合并成一次，大幅减少 DOM 交互次数。 开发体验与跨平台：写代码时不用手动管理复杂的 DOM 状态变化，只需关注数据变化即可自动渲染。而且因为逻辑都在 JS 层，这套机制还能轻松移植到移动端（如 React Native），一套逻辑多处运行。 虽然现代框架优化后 VDOM 的性能优势在缩小，但它依然是实现声明式 UI 的核心基石。 官方详细解决方案：https://cloud.tencent.com/product/teo... 展开详请

别纠结，直接上 vw（配合 rem 基准），px 是过去式。 首选 vw/rem：这是目前最稳的解法。核心逻辑是 1rem = 10vw。视口变宽，字体和布局自动缩放，不用 JS 监听 resize，性能最好。 怎么干：用 PostCSS 插件（如 postcss-px-to-viewport），开发时按设计稿写 px，编译自动转 vw。省心省力。 px 用在哪：仅限固定元素，比如边框线、图标尺寸。千万别拿 px 做容器宽度或字体。 避坑：iOS Safari 对小于 12px 的字体有最小限制，纯 vw 算太小会显示异常，记得加 min() 或媒体查询兜底。高度别硬用 vh，容易受地址栏伸缩影响，靠内容撑开更靠谱。 总结：布局字体靠 vw，细节固定用 px，自动化转换工具走起，别手写媒体查询，累死人。 官方详细解决方案：https://cloud.tencent.com/product/mlvb... 展开详请

简单说就是控制函数执行频率，别让它“疯跑”。 防抖 (Debounce)：像坐电梯。有人按了，等几秒没人再按才关门。 逻辑：触发后设定时器，期间再触发就重置计时。只有“静止”后才执行最后一次。 场景：搜索框输入（输完再查）、窗口Resize、表单提交。防止频繁请求累死服务器。 节流 (Throttle)：像水龙头。不管怎么拧，单位时间出水量固定。 逻辑：设个时间戳，两次执行间隔必须大于阈值。高频触发时，只保留第一次或最后一次。 场景：滚动加载（无限下拉）、鼠标移动轨迹。保证页面不卡顿。 怎么选？ 要精准结果选防抖；要稳定过程选节流。 手写很简单：防抖靠 setTimeout 清重来，节流靠 Date.now() 算差值。直接上 Lodash 的 _.debounce 和 _.throttle，省心省力。 官方详细解决方案：https://cloud.tencent.com/product/tcop... 展开详请

跨域就是浏览器为了安全，限制不同源（协议、域名、端口任一不同）的请求。简单说，A 网站 JS 不能随便调 B 网站接口。 最靠谱的是后端配 CORS 头 Access-Control-Allow-Origin，这是 W3C 标准，支持所有请求方法。如果前后端都归你管，生产环境用 Nginx 反向代理最稳：前端请求同源 Nginx，Nginx 转发给后端，浏览器根本察觉不到跨域，连代码都不用改。 开发时偷懒可以用 Vite/Webpack 的 devServer proxy，但这只限本地调试，上线没用。JSONP 太老且只支持 GET，早该扔了。记住，跨域是浏览器的锅，服务器间互调没这毛病。别在前端硬刚，要么后端配合，要么中间加层代理，这才是正解。 官方详细解决方案：https://cloud.tencent.com/product/cos... 展开详请

选择 **Flex** 还是 **Grid** 的关键在于你要解决的问题形态：**一维布局用 Flex**（例如“同一行/同一列内的元素横向或纵向排列、自动撑开、对齐、换行”），**二维布局用 Grid**（例如“需要同时控制行和列、做复杂栅格、区域布局、响应式栅格体系”），经验上：当你发现自己在用 Flex 还得额外“手动计算行列/做区域占位”时就该改用 Grid；当你只是要控制一条方向的排列与对齐时用 Flex 会更简单更直观。... 展开详请

从输入 URL 到页面渲染，这趟旅程其实是一场精密的接力赛。 首先，浏览器检查缓存，若命中直接展示；未命中则解析域名，通过 DNS 查询获取服务器 IP。接着，建立 TCP 连接（三次握手），若是 HTTPS 还需经过 TLS 握手加密协商。 随后，浏览器向服务器发送 HTTP 请求，服务器返回 HTML 响应。浏览器开始解析 HTML，构建 DOM 树；同时加载 CSS、JS 等资源，解析 CSS 生成 Render Tree（渲染树）。此时，DOM 和 CSSOM 合并，确定每个节点的样式和位置。 接下来是布局阶段（Layout/Reflow），计算元素在屏幕上的确切坐标和大小；然后是绘制（Paint），将像素填色；最后是合成（Composite），将各层内容组合并显示在屏幕上。如果是 JS 动态修改了 DOM，上述流程可能重复执行，直到最终呈现用户看到的页面。 官方详细解决方案：https://cloud.tencent.com/product/dns... 展开详请

先测再决策，别上来就猜。用 Lighthouse 或真实用户数据确认 LCP 元素是啥，多数场景是首屏大图，少数是字体或渲染阻塞。如果是图片：优先级最高的是 hero 图换现代格式压缩、加 fetchpriority=high、preload 预加载，懒加载千万别用在 LCP 元素上，这是最常见的反模式。图片搞定后还超标，再看关键 CSS：首屏内联、其余异步，砍掉阻塞渲染的第三方脚本。决策顺序：确认 LCP 元素、资源（图片/字体）、关键路径 CSS 和 JS、服务端 TTFB。TTFB 高的话前面都白搭，得先查 CDN 命中率和后端响应。不测就内联 CSS 经常白干，图片才是八成场景的元凶。... 展开详请

因为 React 靠“调用顺序”认钩子，不是靠名字。 你第一次渲染时，React 在内存里建了个链表： useState useEffect useContext... 下次渲染，它按同样顺序再走一遍，把新值填进对应位置。要是你把 useState 包在 if (condition) 里，条件一变，调用顺序就乱了。比如上次没执行，这次执行了，React 就会把 A 的值错当成 B，状态直接串台，引发难以调试的 Bug。 简单说：钩子必须像函数定义一样稳定存在，不能随逻辑分支跳来跳去。 保持顺序一致，React 才能准确追踪每个组件的状态。 官方详细解决方案：https://cloud.tencent.com/product/im... 展开详请

JavaScript **闭包**指的是：一个函数在其**外层作用域已经执行结束**后，仍然能“记住/访问”外层变量的能力；因此外层变量不会被垃圾回收，函数会形成对这些变量的引用。典型使用场景包括：①做**数据私有化**（用函数作用域把变量藏起来，只暴露接口），例如模块/封装计数器；②实现**工厂函数**或**参数预置**（返回带已配置参数的新函数，比如 `makeAdder(5)` 生成“加5”的函数），常用于回调与事件处理；③**柯里化**与函数组合（多次传参生成最终处理函数）；④在异步/事件回调里**保持当次的上下文或状态**（例如点击时保存当前选项，回调结束后仍能用到）；⑤节流/防抖等需要维护“上次调用时间/定时器句柄”的逻辑。... 展开详请

Vue 3 相比 Vue 2 的核心区别主要在于：**底层性能与编译/渲染机制**（Vue 3 使用 Composition API、基于 Proxy 实现响应式，通常更高效且对类型推断更友好）、**更好的逻辑复用方式**（Vue 2 主要依赖 Options API，而 Vue 3 提供 `setup` 与 Composition API 便于组合复杂逻辑）、**生态与能力增强**（如改进的生命周期/响应式细粒度更新、Fragment/Teleport/Suspense 等能力更完整），以及**工程化与迁移成本**（Vue 3 对部分 API 有变动，需评估 `v-model` 行为、生命周期钩子命名等差异，但整体向后不完全兼容）。... 展开详请

服务端超时本质是“请求发了，但没收到腾讯的明确回执”。这时候票据（Ticket）处于灰色地带：它可能已经失效，也可能还有效。 处理原则就一条：宁可误杀，不可放行。 具体步骤： 立即丢弃票据：不要重试校验同一个 Ticket，因为验证码是一次性的，重复使用必失败。 要求用户重新验证：前端提示“网络异常，请重新获取验证码”，走正常流程再拿一个全新的 Ticket。这是最安全、最简单的做法。 不要静默放行：绝对不要因为超时就认为“可能成功”而放行用户，这会留下巨大的安全风险（暴力破解、短信轰炸）。 日志记录：将超时的 Ticket 和用户 IP 记录下来，用于后续分析是否遭遇恶意攻击。 为什么不能重试？ 腾讯云接口设计为单次有效。即使第一次请求因网络波动超时，只要腾讯服务器已处理并标记为“已使用”，再次提交就会返回 Invalid Code。 如果腾讯还没处理完（极小概率），重试可能导致并发问题或状态不一致。 最佳实践： 设置合理的超时时间（建议 3-5 秒），不要太短。 前端增加“防抖”和“重试限制”，避免用户频繁点击导致请求堆积。 如果业务对体验要求极高，可考虑引入本地风控（如设备指纹、行为分析）作为辅助判断，但核心校验必须依赖腾讯云返回的成功结果。 官方详细解决方案：https://buy.cloud.tencent.com/captcha... 展开详请

结论：技术越快，新问题主要出在“安全、可靠、治理、人”四个层面，而不是技术本身。下面按工程视角梳理。 一、安全与隐私 1. 攻击面扩大：云原生、微服务、API 数量暴增，每个接口都是潜在入口，常见问题有越权访问、密钥泄露、供应链投毒（依赖包被植入恶意代码）。 2. 数据合规：个人信息保护法、数据出境等要求提高，数据分级分类、加密存储、访问审计需要在设计阶段就考虑。 3. AI 带来的新风险：提示词注入、训练数据泄露、深度伪造导致的诈骗。 应对思路：最小权限、密钥统一托管并定期轮换、依赖扫描与 SBOM、关键数据落盘加密、全链路审计日志。 二、系统复杂度与可靠性 1. 架构层层叠加后，一次故障可能跨越多个服务，定位困难。 2. 过度依赖单一云厂商或单一可用区，会放大故障影响。 3. 变更频率高，发布本身成为故障的主要来源。 应对思路：多可用区部署、限流熔断与降级、灰度发布和快速回滚、统一的监控告警与链路追踪，并定期做故障演练。 三、AI 与自动化的治理问题 1. 大模型输出存在幻觉，直接用于业务决策有风险，需要人工复核或规则兜底。 2. 版权与责任归属不清：生成内容的版权、出错后谁负责，目前仍在逐步明确。 3. 算力和能耗成本上升，需要关注资源利用率。 应对思路：关键场景保留人在回路，输出做校验与留痕，按需弹性使用算力，避免长期闲置。 四、人与社会层面 1. 技能迭代快，从业者需要持续学习，重复性岗位被自动化替代。 2. 信息过载与算法推荐造成信息茧房，注意力被占用。 3. 数字鸿沟：不同人群、地区获取技术红利的能力不均衡。 应对思路：企业做好培训和岗位转型，个人建立稳定的知识体系而不是追逐每个新名词；产品设计上兼顾老年人和弱势群体的可用性。 五、对开发者的建议 - 把安全、可观测性、成本当作与功能同等重要的需求。 - 新技术先在边缘业务试点，再逐步推广。 - 关注标准和法规变化，提前留出合规余地。 总体来说，技术发展本身是中性的，新问题大多来自使用方式和治理缺位，提前做好安全、可靠性和合规设计，可以把大部分风险控制在可接受范围内。... 展开详请