HTML CSS JS 在前端开发时所处的角色？
HTML、CSS 和 JavaScript 共同构成了前端开发的“铁三角”，它们分别承担着结构、表现和行为的核心职责，三者缺一不可且紧密协作。
HTML 是网页的骨架与内容基础。 它通过语义化的标签（如 header、nav、article）定义页面的逻辑结构和信息层级，不仅决定了浏览器如何渲染内容，更直接影响搜索引擎优化（SEO）和无障碍访问（Accessibility）。在面试中，强调 HTML 的语义化而非滥用 div 标签，能体现你对代码可维护性和规范性的理解。
加分点
语义化的标签 可以 优化搜索引擎（SEO）和实现无障碍访问（Accessibility）
CSS 负责页面的视觉表现与布局。 它在 HTML 骨架之上添加颜色、字体、间距等样式，并利用 Flexbox 和 Grid 等现代布局技术确保页面在不同设备上都能完美呈现（响应式设计）。理解 CSS 的层叠优先级（Specificity）以及如何避免重排（Reflow）导致的性能问题 加分点
CSS 的层叠优先级（Specificity）以及如何避免重排（Reflow）导致的性能问题，实现响应式设计
JavaScript 则是赋予页面生命力的肌肉与神经。 它负责处理用户交互、动态修改 DOM 结构、操作样式以及通过异步请求（Promise/async-await）与后端交换数据。现代前端开发中，JS 更是框架（如 React、Vue）的基石，核心在于如何通过逻辑控制让静态页面“活”起来，响应用户的每一次点击与输入。
总结来说，三者的协作流程通常是： HTML 搭建好空的容器结构，CSS 预先定义好美观的样式规则，而 JavaScript 则在运行时动态获取数据并填充内容，同时监听用户事件来触发相应的视觉或逻辑反馈。如果把网页比作一个人，HTML 是骨骼，CSS 是皮肤与衣着，JavaScript 则是让这个人能跑能跳、能交流的动作与思维。
JS闭包以及使用场景
更具体的讲解可以看这篇： JavaScript 词法作用域与闭包：从底层原理到实战理解
闭包（Closure） 是 JavaScript 中最核心也最容易让面试官眼前一亮的概念之一。简单来说，闭包就是“函数 + 函数内部能访问到的词法环境”的组合。
通俗地讲，当一个内部函数被返回或传递到外部后，它依然能够“记住”并访问其定义时所在的外部函数的变量，即使外部函数已经执行完毕。这种“记忆”能力，就是闭包。在 JS 中，函数创建时就绑定了其作用域链，只要内部函数还在被引用，外部函数的变量就不会被垃圾回收机制清除，从而形成了闭包。
闭包的核心使用场景：
首先是数据私有化（模拟私有变量） 。这是闭包最经典的用途。由于 JS 早期没有原生的 private 关键字，我们利用闭包让变量只存在于内部函数的作用域中，外部无法直接修改，只能通过提供的特定接口（getter/setter）来访问。这在编写模块、类或防止全局变量污染时非常有用，比如创建一个计数器，外部只能调用 increment() 而不能直接篡改计数值。
其次是函数柯里化（Currying）和参数复用。闭包允许我们将一个多参数函数拆分成一系列单参数函数，每次调用返回一个新函数并“记住”已传入的参数。这在处理事件监听、配置默认参数或构建灵活的工具函数库时非常常见，能够极大地提高代码的复用性和灵活性。
最后是保持状态（如在循环或异步操作中） 。在早期的 var 声明中，开发者常利用闭包在 for 循环中为每个迭代创建独立的作用域，确保异步回调（如 setTimeout）能获取到正确的索引值。虽然现在可以用 let 块级作用域解决，但理解这一场景能体现你对 JS 执行上下文和事件循环的深刻理解。
面试提示： 回答完定义和场景后，如果能主动补充闭包的缺点（如滥用会导致内存泄漏，因为变量常驻内存），会显得你的技术视野更全面、更严谨。
防抖节流
如何实现的。具体可以看看这篇文章 深入防抖与节流：从闭包原理到性能优化实战
防抖（Debounce） 和节流（Throttle） 是前端性能优化中处理高频事件（如窗口缩放、滚动、输入框输入、按钮点击）的两种核心手段。它们的共同目标是限制函数的执行频率，避免浏览器因短时间内处理大量计算或DOM操作而卡顿，但两者的触发逻辑截然不同。
防抖的核心逻辑是“最后一次说了算” 。它规定在事件被触发后，只有当一段时间内不再有新的事件触发时，回调函数才会执行。如果在规定时间内事件再次被触发，计时器会重置，之前的等待作废。这就好比坐电梯，门快要关时如果有人进来，关门计时器就会重置，直到最后一个人进来且无人再进，门才会真正关上。典型场景包括：搜索框的自动联想（用户停止输入后再发送请求）、窗口大小调整（resize结束后再计算布局）以及表单提交的防止重复点击。
节流的核心逻辑则是“固定时间执行一次” 。它规定在单位时间内，无论事件触发了多少次，回调函数只执行一次。一旦执行，必须等待设定的时间间隔过后，才能响应下一次触发。这就像地铁进站，不管站台上有多少人，车门打开后让人进去，然后必须等固定的发车间隔才能开下一趟。典型场景包括：页面滚动加载（scroll事件中每隔几百毫秒检测一次位置）、鼠标移动轨迹绘制（mousemove）以及拖拽元素的跟随效果。
在面试中区分两者的关键在于时间轴的理解：防抖是推迟执行，关注的是“静止”后的动作，适合处理“最终状态”；节流是间隔执行，关注的是“过程”中的节奏，适合处理“连续动作”。实现上，两者通常都依赖 setTimeout 或时间戳来判断，但防抖需要清除旧的定时器，而节流则需要判断当前时间与上次执行时间的差值。正确选择并实现它们，能显著提升页面的流畅度和用户体验。
HTTP常见的请求方法
HTTP 协议定义了多种请求方法（也称为“动词”），用来指示服务器对指定资源执行何种操作。除了 GET 和 POST，常见的还有 PUT、DELETE、PATCH、HEAD 和 OPTIONS，它们共同构成了 RESTful 架构风格的基础。
核心的增删改查方法主要包括四种：POST 用于创建新资源（提交数据）；GET 用于获取资源（只读，不修改数据）；PUT 用于全量更新资源，即客户端发送的数据会完全替换服务器上的旧资源，如果资源不存在则可能创建；DELETE 用于删除指定的资源。这里需要特别注意 PUT 和 PATCH 的区别：PUT 是“整体替换”，比如修改用户信息时必须传所有字段；而 PATCH 是局部更新，只发送需要修改的字段（例如只改手机号），服务器会将这些变更合并到现有资源中，这在现代 API 设计中越来越常用，能节省带宽并减少并发冲突。
辅助性与探测性的方法主要有三个：HEAD 方法与 GET 类似，但服务器只返回响应头（包含元数据如内容长度、最后修改时间），不返回具体的响应体，常用于检查文件是否存在或获取缓存信息；OPTIONS 方法用于获取目标资源所支持的通信选项，它在前后端分离开发中至关重要，因为浏览器在发送跨域复杂请求前，会自动先发一个 OPTIONS 请求（预检请求）来确认服务器是否允许该操作；此外还有 CONNECT（用于建立隧道，常配合 HTTPS 代理）和 TRACE（用于回环测试，诊断请求路径），这两个在日常业务开发中较少直接使用。
总结来说，理解这些方法的关键在于掌握它们的语义和幂等性。GET、PUT、DELETE、HEAD、OPTIONS 通常被认为是幂等的（多次执行结果与一次执行相同），而 POST 和 PATCH 通常不是幂等的（多次提交可能创建多个资源或产生累积效应）。在面试或实际开发中，遵循“语义化”原则（即用什么方法就做什么事，不要滥用 POST 做所有事情），能让你的 API 设计更加规范、清晰且易于维护。
get和post请求方法的区别
HTTP 的 GET 和 POST 是前端开发中最常用的两种请求方法，它们的核心区别主要体现在语义用途、数据传输方式、安全性以及幂等性上。
从语义和用途来看，GET 请求主要用于获取数据，它向服务器查询资源，不应产生副作用（即不会修改服务器上的数据）；而 POST 请求主要用于提交数据，用于创建新资源或触发服务器端的处理逻辑（如表单提交、文件上传）。这是 RESTful 风格设计的基础原则。
在数据传输方式上，两者有显著不同。
GET 请求将参数直接拼接在 URL 后面（查询字符串），这意味着数据对用户可见，且受限于 URL 的最大长度（不同浏览器限制不同，通常在 2KB 到 8KB 之间），因此不适合传输大量数据。
相反，POST 请求将数据放在 HTTP 请求体（Request Body） 中，理论上没有大小限制，可以传输大量文本、二进制文件等复杂数据，且参数不会直接显示在地址栏里。
关于安全性和缓存，虽然两者在不使用 HTTPS 时都不安全（都可被抓包,都是明文传输），但 GET 请求因为参数暴露在 URL 中，更容易被记录在浏览器历史、服务器日志或代理服务器中，因此绝对不能用于传输密码等敏感信息。此外，GET 请求通常是幂等的（多次执行结果相同）且可被浏览器主动缓存，而 POST 请求默认不会被缓存，且多次提交可能导致重复创建资源（非幂等）。
如果在面试中被问到，可以先用一句话概括：“GET 用于获取数据，参数在 URL 中，不安全且有限长；POST 用于提交数据，参数在请求体中，更适合传输敏感或大量数据。”随后可以补充提到幂等性（Idempotency）的概念：GET 是幂等的，多次调用不会产生额外影响；而 POST 不是幂等的，多次调用可能会创建多个资源。这能体现你对 HTTP 协议规范的深入理解。
http 状态码
HTTP 状态码是服务器对客户端请求的响应反馈，由三位数字组成。首位数字定义了响应的类别，后两位数字没有分类作用。理解这五大类状态码是前端调试、后端开发以及运维排查问题的基础。
1. 2xx 成功（Success）
表示请求已成功被服务器接收、理解并接受。
- 200 OK：最常见的状态码，表示请求成功，响应体中包含请求的资源。
- 201 Created：通常用于 POST 或 PUT 请求，表示资源创建成功，响应头中通常包含新资源的
LocationURL。 - 204 No Content：表示请求成功，但响应体中没有内容（常用于 DELETE 请求或更新操作不需要返回数据时）。
2. 3xx 重定向（Redirection）
表示需要客户端采取进一步的操作才能完成请求，通常用于页面跳转或资源迁移。
- 301 Moved Permanently：永久重定向。资源已永久移动到新位置，浏览器和搜索引擎会更新缓存，下次直接访问新地址（利于 SEO）。
- 302 Found：临时重定向。资源暂时移动，浏览器下次仍应访问旧地址。
- 304 Not Modified：协商缓存。这不是真正的重定向，而是告诉浏览器“你本地的缓存没过期，直接用吧”，服务器不返回资源内容，极大节省带宽。
3. 4xx 客户端错误（Client Error）
表示请求包含语法错误或无法完成请求，问题出在客户端（如前端传参错误、权限不足）。
- 400 Bad Request：通用错误，表示请求报文存在语法错误，服务器无法理解。
- 401 Unauthorized：未授权。表示用户未登录或令牌（Token）无效，需要重新认证。
- 403 Forbidden：禁止访问。服务器理解请求，但拒绝执行（通常是因为权限不足，即使登录了也没权看）。
- 404 Not Found：未找到。服务器找不到请求的资源（路径错误或资源被删除）。
- 405 Method Not Allowed：请求方法不被允许（例如对只读接口发了 POST 请求）。
4. 5xx 服务器错误（Server Error）
表示服务器在处理请求的过程中发生了错误，问题出在服务端（如代码崩溃、数据库连不上）。
- 500 Internal Server Error：通用的服务器内部错误，通常是后端代码抛出异常或未捕获的错误。
- 502 Bad Gateway：网关错误。作为网关或代理的服务器（如 Nginx），从上游服务器（如 Node.js/Java 应用）收到了无效的响应。
- 503 Service Unavailable：服务不可用。服务器暂时过载或正在维护，无法处理请求（通常伴随
Retry-After头）。 - 504 Gateway Timeout：网关超时。上游服务器在规定时间内没有响应给网关。
在实际开发和面试中，除了背诵定义，更重要的是排查思路：
- 看到 4xx，首先检查前端代码：URL 拼写、参数格式、Token 是否过期、权限配置。
- 看到 5xx，首先联系后端或查看服务器日志：数据库连接、代码逻辑异常、服务器负载。
- 特别关注 304（缓存优化）、401/403（鉴权逻辑区分）以及 502/504（微服务架构或反向代理中的常见网络问题），这些能体现你对系统架构的理解。
