前端2月19日 15:58
React、Vue、Angular 防 XSS 靠什么？哪些场景会失效？## 直接回答
React、Vue、Angular 都会默认把模板里的普通文本做 HTML 转义，所以把用户昵称、搜索词、评论摘要渲染成文本时，一般不会直接变成脚本执行。真正的风险通常出现在开发者主动绕过框架保护：React 的 `dangerouslySetInnerHTML`、Vue 的 `v-html`、Angular 的 `bypassSecurityTrustHtml`，以及把不可信数据拼到 URL、CSS、事件处理器或第三方组件配置里。框架能减少常见错误，但不能替你判断一段 HTML 是否可信，也不能保证后端、富文本编辑器、Markdown 渲染器和广告脚本都安全。
防 ...
乐闻
服务端2月19日 16:20
Consul 服务发现是如何完成注册、健康检查和查询的？Consul 的服务发现可以拆成三步：服务把地址、端口和健康检查注册到本机 Consul Agent；Agent 定期执行检查，并把状态同步到 Consul server；调用方通过 DNS 或 HTTP API 查询健康实例，再由客户端、网关或负载均衡器决定访问哪一个。关键点是服务通常不是直接注册到远端 server，而是注册到同机或同网段的 client agent。这样服务上下线、健康检查和网络抖动都先在本地处理，server 负责维护一致的服务目录。
服务定义可以放在 `/etc/consul.d/web.json`：
```json
{
"service": {
...服务端2月19日 16:22
Consul 多数据中心部署如何配置？哪些坑最容易踩？Consul 的多数据中心不是把一个 Raft 集群横跨几个机房，而是每个数据中心有自己的 Consul server 集群，再通过 WAN Gossip 和远程 RPC 互相发现。这样做的好处是本地故障不会直接拖垮其他数据中心，服务查询也优先走本地。代价是 KV、ACL、服务目录并不是天然全局一致，跨数据中心访问要明确指定目标 DC。很多误解都来自这里：Consul 支持联邦，不等于自动同步所有配置和业务流量。
常见生产结构是每个数据中心 3 或 5 个 server，业务机器运行 client agent。server 参与 Raft，client 负责本机服务注册、健康检查和转发...服务端2月19日 16:25
Consul、Eureka、ZooKeeper 和 etcd 做服务发现该怎么选？选服务发现工具时，不能只看功能表，要先看团队到底要解决什么问题。Consul 的强项是把服务注册发现、健康检查、DNS 查询、多数据中心和 KV 能力放在一起，适合多语言、跨机房、非 Kubernetes 专用的服务治理场景。Eureka 更贴近 Spring Cloud 老体系，Java 应用接入顺手，但 2.x 已停止活跃演进，新项目不太建议从零押注。ZooKeeper 和 etcd 都能作为注册发现的底层存储，但它们更偏分布式协调或强一致 KV，健康检查、服务模型和 DNS 接入通常要自己补。
Consul 的最小服务注册大概是这样：
```json
{
"service"...前端2月19日 16:29
whistle 代理工具适合解决哪些前端调试问题？whistle 是基于 Node.js 的本地代理调试工具，常用来抓包、改请求、改响应、做接口 Mock、切换测试环境和调试移动端流量。它不像 Charles、Fiddler 那样主要依赖图形化操作，而是把很多能力放进规则文本里，适合前端团队沉淀一套可复制的调试方案。这个取舍很现实：规则可共享、可复用，但第一次配置代理、证书和规则时更容易出错。
安装一般只需要 Node 环境：
```bash
npm install -g whistle
w2 start
w2 status
```
启动后默认控制台是 `http://127.0.0.1:8899`。浏览器或手机把 HTTP/HT...前端2月19日 16:31
Whistle 如何做接口数据模拟，resBody 和 resScript 怎么选？Whistle 做数据模拟，最常见的目标不是“造一份假数据”这么简单，而是让前端在后端未完成、接口异常、网络慢、登录态变化时都能继续开发。选方法时可以先问一句：这个响应是固定的，还是要根据参数、请求头、登录状态动态变化？固定数据用 `resBody` 和 Values 更省事，动态逻辑再上 `resScript` 或插件。
## 固定响应用 resBody
如果只是让某个接口返回一段稳定 JSON，`resBody` 是成本最低的方式。它适合登录信息、配置开关、列表空态、错误码等场景。为了可维护，不建议把很长的 JSON 直接写在规则行里，最好放到 Values 文件中。
```t...前端2月19日 16:31
如何开发 Whistle 插件，基本目录和入口逻辑怎么设计？开发 Whistle 插件时，先别急着写复杂的拦截逻辑。一个好插件至少要回答三件事：它提供什么协议或规则能力，配置从哪里来，出错时怎样不影响正常代理。插件适合做团队可复用的能力，比如统一鉴权头、动态 mock、请求审计、环境面板；如果只是临时改一个接口，用普通 rules 和 values 更轻。
## 插件项目应该长什么样？
Whistle 插件本质上是一个 npm 包，包名通常使用 `whistle.xxx` 或团队约定的插件名。最小结构包括 `package.json`、入口文件、可选的 rules、values、README。入口文件负责注册服务逻辑，配置文件负责描述插件名称...前端2月19日 16:32
如何用 Whistle 调试移动端 App，代理和证书怎么配置？用 Whistle 调试移动端应用，本质是让手机的 HTTP/HTTPS 流量先经过电脑上的 Whistle，再由 Whistle 转发到真实服务或 mock 服务。步骤不难，难点通常在三处：手机连不到电脑代理、HTTPS 证书没被系统信任、App 自己做了证书绑定。只要按顺序排查，移动端抓包和改包会稳定很多。
## 先确认电脑端 Whistle 可访问
电脑上启动 Whistle，默认端口是 `8899`。如果团队里端口有冲突，可以显式指定端口，但手机代理里也要填同一个端口。启动后先在电脑浏览器打开 `http://127.0.0.1:8899/`，确认控制台能进入。
```ba...前端2月19日 16:33
Whistle 规则如何管理，团队协作时怎样避免配置冲突？Whistle 的规则管理不要只理解成“谁在网页里改几行配置”。个人调试时，Web 界面足够快；团队协作时，真正麻烦的是规则来源、环境切换、命名规范和回滚机制。如果这些没有约定，今天 A 同学为了联调把接口代理到本地，明天 B 同学拉到同一份规则后就可能误连错环境。
## 规则应该放在哪里管理？
日常临时调试可以直接打开 `http://127.0.0.1:8899/`，在 Rules 面板里写规则并保存，适合验证某个接口、替换一个静态资源、临时 mock 一段响应。它的好处是所见即所得，Network 面板马上能看到命中情况；缺点是改动容易散落在个人机器上，别人不知道你改了什么。
...前端2月19日 16:33
whistle 如何用脚本处理请求响应并避开常见坑？whistle 的脚本能力适合处理规则表达不了的逻辑，比如按请求参数动态改 header、根据用户身份返回不同 mock、给响应体追加字段，或者把线上接口临时改造成前端需要的数据形状。规则更像声明式配置，脚本则是命令式处理；能用规则解决的别急着写脚本，因为脚本越多，调试成本和副作用也越高。它的边界也很明确：脚本运行在代理链路里，任何慢逻辑都会拖慢请求，任何不严谨的匹配都可能影响无关流量。
先准备一个本地脚本文件，例如 `change-user.js`：
```javascript
module.exports = (req, res) => {
req.headers['x-de...