我眼中的技术世界
T1：TypeScript 中命名空间与模块的理解？区别？模块（Module）：ES6 标准，基于文件的模块系统（import / export）；可以是 export 任何顶级声明（变量、函数、类、接口）；由模块加载器（ESM、CommonJS、AMD）负责依赖管理。命名空间（Namespace）：TypeScript 早期为解决全局变量污染引入的内部模块机制；使用 namespace X { ... } 声明，内部 export 导出成员；最终被编译为 IIFE，依赖全局对象；不推荐在新项目使用，仅适用于声明文件（.d.ts）和全局类型扩展。// 命名空间（不推荐） namespace Utils { export function format(date: Date) { /* ... */ } } // 模块（推荐） // utils.ts export function format(date: Date) { /* ... */ }区别对比：维度模块命名空间范围文件级块级加载模块系统全局对象推荐场景所有现代项目仅 .d.ts 中使用T2：TypeScript 是什么？
前端性能指标是衡量网页加载速度、交互流畅度和视觉稳定性的重要依据，对于优化用户体验至关重要。 FP (First Paint) First Paint（首次绘制）标志着浏览器开始在屏幕上渲染任何内容，包括背景颜色改变。这是用户看到页面开始加载的第一个视觉反馈。尽管FP是一个相对宽泛的指标，但它能快速给出页面开始加载的初步指示。 FMP (First Meaningful Paint) First Meaningful Paint（首次有效绘制）是页面主要内容开始呈现给用户的时刻。这个指标更关注于用户感知，即用户开始看到页面上他们认为“有意义”的内容。FMP已经被LCP（Largest Contentful Paint）所替代，因为LCP提供了更准确的度量标准。 LCP (Largest Contentful Paint) Largest Contentful Paint（最大内容绘制）衡量的是页面上最大的可见元素（文字块或图像）变为可见所需的时间。这是用户感知页面加载完成的重要标志，直接影响到用户感受到的速度。LCP应该尽快发生，理想情况下在2.5秒内。 CLS (C
在当今设备多样化、应用复杂的世界里，构建高效且用户友好的用户体验至关重要。微服务架构的兴起为后端开发带来了诸多好处，但也为需要与多个后端服务交互的前端应用程序带来了挑战。这就是后端前端 (BFF) 模式的用武之地。>BFF 模式是一种架构模式，专门设计用于通过为每个前端应用程序创建专用后端来满足不同客户端的需求。这意味着，您不需要拥有一个试图为所有客户端提供服务的通用 API，而是拥有一个充当前端和微服务之间的适配器的 BFF 层。为什么要实现 BFF 模式？前端后端模式在 Web 开发中提供了多种优势：优化用户体验：每个 BFF 都根据其相应前端应用程序的特定需求进行量身定制，允许前端开发人员优化用户界面和数据流。例如，移动应用程序 BFF 可能优先考虑轻量级 JSON 响应和高效的数据聚合，而 Web 应用程序 BFF 可能专注于更丰富的数据结构和更复杂的交互。简化前端开发：通过抽象微服务架构的复杂性，BFF 为前端提供了单个 API 进行交互。这减少了对单个微服务的依赖，并简化了客户端的数据获取逻辑，使前端团队可以专注于构建用户界面，而无需担心后端的复杂性。提高后端敏捷性：只要
我们在需求阶段经常会遇到下列问题，针对直播抢购场景，假设我们要设计一款直播抢购的功能，比如某网红的直播间粉丝过亿，500万人在线，100万单商品瞬间被抢，下单并发高达200万QBS，如果当时出现评论区卡死，商品白屏，连库存服务也挂了，订单系统也崩溃了，这应该怎么办？分析：首先这是普通的技术难题，库存服务挂了，订单系统也跟着崩了，那肯定是服务依赖没处理好，或者说是这个全链路这个压测不到位，引发了连锁反应。问：系统缺乏防护机制的原因是什么？答：我认为系统缺乏防护机制的原因主要有三个。首先，流量失控没有限流措施，导致高并发直接压垮了系统。其次，服务之间的强依赖耦合太紧，一个服务出现问题，其他服务也会受到影响。最后，隔离措施不足，资源和逻辑没有有效隔离，单点故障迅速蔓延，导致整个系统瘫痪。问：如何设计以避免这种局面？答：我会采取三个主要策略来解决这个问题。首先，拦截，通过限流和熔断机制拦截和限制流量，比如设定阈值，超过阈值时进行限流或降级，以保护服务不被压垮。其次，缓解，通过缓存和排队等方式缓解流量高峰，提升系统吞吐能力。最后，隔离，通过隔离故障域，将问题限制在局部，防止故障蔓延到整个系统。问
在JavaScript中确实存在一些著名的"怪异"案例，这些都是由JavaScript的类型转换和比较规则导致的。以下是一些典型例子：相等性比较：[] == ![] // true [] == false // true '' == false // true null == undefined // true [1,2] == '1,2' // true针对第一个 [] == ![] 返回true是因为类型转换问题，其详细过程如下：首先，![] 会被计算：[] 是一个对象，转换为布尔值时为true!true 得到false此时表达式变成了[] == false当对象与布尔值比较时，两边都会被转换为数字：[] 会先被转换为原始值，调用toString()得到空字符串""空字符串转换为数字得到0false转换为数字也是0最终变成了0 == 0 ，所以返回true类型转换： [] + [] // ""（空字符串） [] + {} // "[object Object]" {} + [] // 0 true + true // 2数值
互联网发展迅猛之余也伴随着互联网寒冬，行业不景气这样的词，等毕业季去各个求职网站投简历，去各个人才市场找机会，才发现四处碰壁，作为应届求职者更需要打好基础，明确发展规划，跟上行业步伐。下面是本人2019年秋招前端面试经历，结合个人博客和牛油们面经中的高频问题以及行业前辈们复习资料的综合整理，包含基础篇、Vue框架篇、HTTP&浏览器、构建工具篇、安全篇、算法篇，欢迎交流斧正。希望大家在毕业季都能一帆风顺，从容斩获OFFER 怀着学习的态度完成了一份90页PDF ， 近140+commits，近100+前端面试题及推荐解答，资源合集的面试小册。因为篇幅有限，下面是小册前三篇的各五道前端高频面试题及推荐解答，这个项目已经在github上开源，欢迎大家取用：https://github.com/okaychen/FE-Interview-Brochure 浏览器解析渲染页面过程 大致过程： HTML解析构建DOM-CSS解析构建CSSOM树-根据DOM树和CSSOM树构建render树-根据render树进行布局渲染render layer-根据计
V1：Vue 有了数据响应式，为何还要 diff？原因：响应式只能解决“是否要更新”问题：当响应式数据变化时，Vue 知道“该重新渲染了”，但不知道具体要改哪里。Vue 的粒度不是单一变量：一个组件模板中可能有多个数据依赖，状态变化后需要重新执行 render 函数生成新的 VNode。diff 负责高效比较新旧 VNode 树：找出最小 DOM 操作，应用到真实 DOM。性能优化关键：diff 使用双端对比 + 最长递增子序列算法，复杂度从 O(n³) 降到 O(n)。总结：响应式负责调度，diff 负责精准更新。V2：Vue 3 为什么不需要时间分片？原因：响应式粒度更细：Vue 通过 Proxy 精确知道哪个响应式数据变化，且只触发使用了该数据的组件重新渲染。静态提升 + 补丁标记：编译期优化避免了大量 VNode 比较。组件级调度：默认一个组件一个更新任务，粒度适合，不容易产生超长任务。框架定位不同：Vue 设计为“渐进式”，默认不启用并发模式，代码量与心智负担更低。React 为什么需要：不可变数据 + setState 模型下，一次更新可能涉及大量组件（任何依赖该状态的组件
Q1：Fiber 架构的工作原理？核心要点：Fiber 是 React 16 引入的协调引擎（Reconciliation Engine），将渲染工作拆分成可中断、可恢复的最小工作单元。工作原理：数据结构：每个 Fiber 节点对应一个 React 元素，包含 type、key、child、sibling、return、pendingProps、memoizedProps、memoizedState、alternate（双缓冲）等字段，形成一棵 Fiber 树。双缓冲机制：维护两棵 Fiber 树（current 和 workInProgress），更新时构建 workInProgress，完成后整体切换，减少页面闪烁。两阶段渲染：Render 阶段（可中断）：调用 beginWork 向下遍历，构建新 Fiber 树，标记副作用（Placement/Update/Deletion）。Commit 阶段（不可中断）：将副作用一次性提交到真实 DOM，调用 useEffect/useLayoutEffect 回调。时间切片（Time Slicing）：通过 MessageChannel
需求描述打造 特定领域知识(Domain-specific Knowledge) 问答 系统，具体需求有：通过自然语言问答的形式，和用户交互，同时支持中文和英文。 理解用户不同形式的问题，找到与之匹配的答案。可以对答案进行二次处理，比如将关联的多个知识点进行去重、汇总等。 支持上下文。有些问题可能比较复杂，或者原始知识不能覆盖，需要从历史会话中提取信息。 准确。不要出现似是而非或无意义的回答。 从大语言模型（Large Language Model, LLM）角度而言，上面的需求是在两阶段训练模式下，面向下游场景进行适配的问题。基础模型(Foundation Model)，面向特定领域不能直接应用，因为领域知识不在预训练的数据集中，比如：较新的内容。同一个知识点不断变更：修改、删除、添加。如何反馈当前最新的最全面的知识。比如对于 ChatGpt 而言，训练数据全部来自于 2021.09 之前。 未公开的、未联网的内容。 方案分析基于 LLM 搭建问答系统的解决方案有以下几种：Fine-Tuning 基于 Prompt Engineering，比如 Few-Shot方式。 与普通搜索结合
ChatGPT 很智能，但是它有不足：知识库老旧，停留在2021年。另外对于企业，很多私有知识，并不希望全部暴露给GPT。因此结合ChatGPT的自然语言对话能力，加上私有知识库的数据，可以发挥更大价值。假如我们想利用OpenAI能力打造基于私有知识库的智能机器人，可以怎么做呢？实现思路当前主流解决方案是使用建立本地向量数据库，用户输入的时候先在本地向量数据库找出相似文本，然后再发给 LLM，让 LLM 帮我们整理答案。（更多内容感兴趣的查看结尾的问答）大概步骤如下：1、将知识库文档向量化（使用OpenAI中的embeddings）后存储到向量数据库（Chroma）;2、对于用户输入，在向量数据库中查询相关文档(如余弦相似算法)并按相似程度排序;3、取最相关的前几个(如 top 5，需要考虑 token 数)作为背景知识，同用户请求一起发送给 LLM，让大模型根据背景知识整理并回答。实现Demo把 LangChain 的文档作为知识库，使用一个智能助手进行问答。先直接看看实现效果我们先问一下ChatGPT（gpt4）:再来问一下基于LangChain文档建立的问答机器人：（效果还是很明
小码哥
十年老程序员
粤ICP备2023052298号-1
