本文通过一个真实的上线案例，详细讲解FastAPI与JavaScript实现WebSocket长连接保持的心跳机制。你会了解为什么连接会断、心跳原理是什么、前后端代码怎么写，以及那些文档里没写的调优陷阱。照着做，让你的实时通信稳如老狗。

你是不是也遇到过——WebSocket连接动不动就断开，尤其是在移动端，用户切换个Wi-Fi或者电梯里信号晃一下，消息就收不到了？用户投诉说“APP消息延迟”，你一查日志，满屏都是WebSocket disconnected，然后疯狂重连，服务器压力山大，用户体验稀碎。

有些项目图省事，觉得WebSocket连上就行了，结果线上跑了半天，运维小哥就发来报警：连接数忽高忽低，很多连接存活不到2分钟。查日志，好家伙，Nginx默认proxy_read_timeout 60秒，加上移动网络运营商会掐掉长时间无流量的连接，双向夹击，连接全断了。

核心结论：WebSocket长连接保持，不能靠“连上就不管”，必须引入心跳机制——就像两个人打电话，每隔一会儿问一句“喂，还在吗？”。今天我就把FastAPI后端 + JavaScript前端的完整心跳实现，掰开了揉碎了讲给你听，顺便把我踩过的坑标红。

本文路线图

• 为什么WebSocket会断？—— 中间件超时、网络状态变化
• 心跳原理：ping-pong 还是 pong-ping？
• FastAPI后端：接收心跳消息 + 超时管理
• JavaScript前端：定时发送心跳 + 断线重连
• 完整可运行代码示例
• 那些年我踩过的坑（间隔设置、重复定时器、服务端主动断开）

🧠 第一部分：连接为什么会断？

把WebSocket想象成一条水管，数据就是水。如果水管一直流水，它就不会堵。但要是你半天不放水，中间的路由器、防火墙就觉得“嘿，这管子是不是废弃了？”——咔嚓一刀给你掐了。尤其是在移动网络下，运营商的NAT网关空闲超时可能只有30秒到几分钟。还有我们常用的Nginx，默认proxy_read_timeout是60秒，一旦60秒内没有数据从后端发到客户端，Nginx就会自作主张断开连接。

所以，要想让连接长存，唯一的方法就是定期发送一些“无用”的数据，告诉中间件：“我还活着，别砍我！”——这就是心跳。

💓 第二部分：心跳机制的两种姿势

心跳本质是一种ping/pong模式。WebSocket协议本身有控制帧Ping和Pong，但浏览器原生JS的WebSocket API并没有直接暴露发送Ping帧的方法，所以我们一般用普通消息模拟：

• 方案A：客户端定时发送ping消息，服务器收到后立即回复pong。
• 方案B：服务器定时发送ping，客户端回复pong。但同样，客户端需要能解析并回复。

更常见的做法是客户端主动发心跳，服务器只需响应或记录。为啥？因为客户端更能感知网络变化，且断开后能立即重连。下面我就以客户端发心跳为例，上代码。

⚙️ 第三部分：FastAPI后端实战

先搭一个最简单的FastAPI WebSocket端点。这里我用了/ws路径，接收心跳消息（约定JSON格式{"type": "ping"}），并回复{"type": "pong"}。同时，为了及时清理死连接，我会记录每个连接的最后心跳时间，启动一个后台任务检查超时（比如60秒没收到心跳就主动close）。

from fastapi import FastAPI, WebSocket, WebSocketDisconnect
import asyncio
import json
from datetime import datetime, timedelta

app = FastAPI()

class ConnectionManager:
    def __init__(self):
        self.active_connections: dict[WebSocket, datetime] = {}
        self._heartbeat_check_interval = 30   # 每30秒检查一次
        asyncio.create_task(self.heartbeat_checker())

    async def connect(self, websocket: WebSocket):
        await websocket.accept()
        self.active_connections[websocket] = datetime.utcnow()
        print(f"新连接加入，当前连接数：{len(self.active_connections)}")

    def disconnect(self, websocket: WebSocket):
        if websocket in self.active_connections:
            del self.active_connections[websocket]
            print(f"连接断开，当前连接数：{len(self.active_connections)}")

    async def handle_messages(self, websocket: WebSocket):
        try:
            while True:
                data = await websocket.receive_text()
                try:
                    msg = json.loads(data)
                except:
                    continue
                # 如果是心跳ping，更新最后心跳时间并回复pong
                if msg.get("type") == "ping":
                    self.active_connections[websocket] = datetime.utcnow()
                    await websocket.send_text(json.dumps({"type": "pong"}))
                else:
                    # 其他业务消息，按需处理
                    await websocket.send_text(json.dumps({"type": "echo", "data": msg}))
        except WebSocketDisconnect:
            self.disconnect(websocket)

    async def heartbeat_checker(self):
        while True:
            await asyncio.sleep(self._heartbeat_check_interval)
            now = datetime.utcnow()
            timeout = timedelta(seconds=70)  # 超过70秒没心跳就断开
            dead_conns = []
            for ws, last_ping in self.active_connections.items():
                if now - last_ping > timeout:
                    dead_conns.append(ws)
            for ws in dead_conns:
                try:
                    await ws.close(code=1000, reason="heartbeat timeout")
                except:
                    pass
                self.disconnect(ws)

manager = ConnectionManager()

@app.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket):
    await manager.connect(websocket)
    await manager.handle_messages(websocket)

💻 第四部分：JavaScript前端实现

前端主要做三件事：建立连接、定时发心跳、监听断开自动重连。我习惯把WebSocket封装成一个类，方便复用。直接上代码：

class WebSocketClient {
    constructor(url) {
        this.url = url;
        this.ws = null;
        this.heartbeatInterval = 30000; // 30秒一次心跳
        this.reconnectInterval = 3000;   // 断线后3秒重连
        this.heartbeatTimer = null;
        this.reconnectTimer = null;
        this.connect();
    }

    connect() {
        this.ws = new WebSocket(this.url);
        this.ws.onopen = () => {
            console.log('WebSocket 已连接');
            // 连接成功后，启动心跳
            this.startHeartbeat();
            // 如果之前有重连定时器，清掉
            if (this.reconnectTimer) {
                clearTimeout(this.reconnectTimer);
                this.reconnectTimer = null;
            }
        };

        this.ws.onmessage = (event) => {
            const data = JSON.parse(event.data);
            if (data.type === 'pong') {
                console.log('收到心跳pong，连接正常');
                // 可以在这里更新UI显示最后心跳时间，但不必须
            } else {
                // 处理其他业务消息
                console.log('业务消息', data);
            }
        };

        this.ws.onclose = (e) => {
            console.log('WebSocket 关闭', e.reason);
            // 停止心跳
            this.stopHeartbeat();
            // 尝试重连
            this.reconnect();
        };

        this.ws.onerror = (err) => {
            console.error('WebSocket 错误', err);
            this.ws.close();
        };
    }

    startHeartbeat() {
        this.heartbeatTimer = setInterval(() => {
            if (this.ws && this.ws.readyState === WebSocket.OPEN) {
                this.ws.send(JSON.stringify({ type: 'ping' }));
                console.log('发送心跳ping');
            } else {
                console.warn('连接未开启，停止发送心跳');
                this.stopHeartbeat();
            }
        }, this.heartbeatInterval);
    }

    stopHeartbeat() {
        if (this.heartbeatTimer) {
            clearInterval(this.heartbeatTimer);
            this.heartbeatTimer = null;
        }
    }

    reconnect() {
        this.stopHeartbeat();
        if (!this.reconnectTimer) {
            this.reconnectTimer = setTimeout(() => {
                console.log('尝试重连...');
                this.connect();
            }, this.reconnectInterval);
        }
    }

    // 主动关闭连接（比如页面卸载时）
    close() {
        this.stopHeartbeat();
        if (this.ws) {
            this.ws.close();
        }
    }
}

// 使用示例
const client = new WebSocketClient('ws://你的域名/ws');
// 页面关闭前主动清理
window.addEventListener('beforeunload', () => client.close());

🧪 第五部分：跑起来看看效果

启动FastAPI（uvicorn main:app --reload），打开浏览器控制台，你会看到每隔30秒发送一次ping，服务器立即回复pong。即使你断开Wi-Fi再打开，客户端也会自动重连，并且重连后心跳继续。🎯

💣 第六部分：那些年我踩过的坑（必看）

• 坑1：心跳间隔太短，服务器压力大——1秒一次纯属自残，30秒一次足够，既保活又省资源。
• 坑2：服务端没做超时主动断开——客户端突然掉线（比如用户强制杀进程），服务端不知道，连接一直占着内存。所以后台心跳检查一定要有，超时就close。
• 坑3：重连时忘记清理旧定时器——每次重连都新建一个setInterval，导致多个心跳线程并发，消息爆炸。解决方案：重连前先stopHeartbeat()。
• 坑4：前后端心跳格式约定不一致——我的是{"type":"ping"，如果你后端用字段heartbeat，一定记得对齐，否则服务器不认，相当于没心跳。
• 坑5：没考虑SSL/加密连接——生产环境用wss://，证书配置要正确，否则连接直接被拒绝。

这篇文章将带你系统掌握FastAPI中静态文件处理的方方面面，不止是简单的“挂载”，更涵盖安全防护、性能技巧和实战坑点，包含一个可直接运行的完整示例。

• 📂 静态文件的加载、存储与应用场景
• 🛡️ 至关重要的静态文件安全设置
• 🎯 一行代码搞定网站favicon
• 🖼️ 处理图片等媒体文件的上传与访问

目录一览

• 🚀 起步：为什么需要处理静态文件？
• 📁 FastAPI的“文件管家”：StaticFiles
• 🔒 给静态文件加把“锁”：安全设置详解
• ⭐ 小图标大学问：Favicon的处理
• 🎬 不止于图片：媒体文件的上传与响应
• 🧪 实战演练：一个完整的示例应用

起步：为什么需要处理静态文件？

你的API很酷，但用户访问 http://localhost:8000/logo.png 却得到404？这是因为FastAPI默认是个纯粹的API框架，它不会自动提供像图片、CSS、JavaScript这样的静态文件。

静态文件是那些内容固定、不经常改变的文件。它们对于构建一个完整的Web应用或API文档门户至关重要。

FastAPI的“文件管家”：StaticFiles

引入 StaticFiles，你就能轻松搭建一个文件服务器。其核心三步法：

• 导入：from fastapi.staticfiles import StaticFiles
• 挂载：将URL路径“挂载”到一个实际目录。
• 应用：使用 app.mount 方法。

from fastapi import FastAPI
from fastapi.staticfiles import StaticFiles

app = FastAPI()

# 将路径 “/static” 映射到项目下的 “static” 目录
app.mount("/static", StaticFiles(directory="static"), name="static")

理解“挂载”：它意味着所有访问 /static/* 的请求，都会由 StaticFiles 实例去 ./static 目录下查找对应文件。它不是API路由，而是一个独立的子应用。

🔒 给静态文件加把“锁”：安全设置详解

开放文件访问是危险的！错误的配置可能导致敏感文件泄露（如 .env、.git 目录）。

1. 限制目录访问范围：永远不要将根目录“ / ”挂载到静态文件服务。务必使用一个独立的、权限明确的子目录（如 static、assets）。
2. 使用“html=True”安全地提供HTML：如果你想提供单页应用（如Vue/React构建的产物），可以设置 html=True，并让 index.html 作为目录的默认页。

# 安全地提供前端构建产物目录
app.mount("/app", StaticFiles(directory="./frontend/dist", html=True), name="spa_app")

注意：html=True 只对提供前端SPA友好，它本身并不是一个安全漏洞。真正的安全在于对 directory 参数的控制。

⭐ 小图标大学问：Favicon的处理

浏览器会自动请求 /favicon.ico。如果你没处理，日志里就会堆满404错误，显得不专业。

最简单的方法：直接把它当成一个静态文件处理。

# 方法：为 favicon.ico 单独设置一个路径路由（或将它放在 static 目录）
from fastapi.responses import FileResponse

@app.get("/favicon.ico")
async def favicon():
    return FileResponse("static/favicon.ico")

这能一劳永逸地消除那个烦人的404请求。

🎬 不止于图片：媒体文件的上传与响应

静态文件是“读”，媒体文件则常涉及“写”（上传）。FastAPI处理上传非常优雅。

• 上传：使用 File 和 UploadFile。
• 存储：使用 shutil 或 aiofiles 写入特定目录（如 media/）。
• 访问：再次借助 StaticFiles 挂载 media/ 目录。

from fastapi import File, UploadFile
import shutil
import os

UPLOAD_DIR = "media"
os.makedirs(UPLOAD_DIR, exist_ok=True)

@app.post("/upload/image/")
async def upload_image(file: UploadFile = File(...)):
    file_path = os.path.join(UPLOAD_DIR, file.filename)
    with open(file_path, "wb") as buffer:
        shutil.copyfileobj(file.file, buffer)
    return {"filename": file.filename, "url": f"/media/{file.filename}"}

# 挂载上传的媒体文件目录
app.mount("/media", StaticFiles(directory="media"), name="media")

🧪 实战演练：一个完整的示例应用

下面是一个整合了上述所有知识点完整的 main.py 文件，复制即可运行体验。

from fastapi import FastAPI, File, UploadFile, Request
from fastapi.staticfiles import StaticFiles
from fastapi.responses import FileResponse, HTMLResponse
import shutil
import os
from pathlib import Path

app = FastAPI()

# 1. 创建必要的目录
static_dir = Path("static")
media_dir = Path("media")
static_dir.mkdir(exist_ok=True)
media_dir.mkdir(exist_ok=True)

# 2. 挂载静态文件目录（存放 CSS，JS，预置图片）
app.mount("/static", StaticFiles(directory=static_dir), name="static")

# 3. 挂载媒体文件目录（存放用户上传的图片）
app.mount("/media", StaticFiles(directory=media_dir), name="media")

# 4. 处理 favicon 请求
@app.get("/favicon.ico", include_in_schema=False)
async def get_favicon():
    # 假设你的 favicon.ico 放在 static 目录下
    return FileResponse(static_dir / "favicon.ico")

# 5. 文件上传接口
@app.post("/upload/")
async def create_upload_file(file: UploadFile = File(...)):
    # 保存上传的文件到 media 目录
    save_path = media_dir / file.filename
    with save_path.open("wb") as buffer:
        shutil.copyfileobj(file.file, buffer)
    # 返回文件的访问 URL
    return {"url": f"/media/{file.filename}"}

# 6. 一个简单的前端页面，用于演示和测试上传
@app.get("/", response_class=HTMLResponse)
async def main():
    return """
    <html>
        <head>
            <title>FastAPI静态文件演示</title>
        </head>
        <body>
            <h2>上传图片测试</h2>
            <form action="/upload/" enctype="multipart/form-data" method="post">
            <input name="file" type="file">
            <input type="submit">
            </form>
            <br>
            <h3>尝试访问：</h3>
            <ul>
                <li><a href="/static/example.txt">预置的静态文件 (/static/example.txt)</a></li>
                <li>上传后，访问：<code>/media/[你的文件名]</code></li>
            </ul>
        </body>
    </html>
    """

运行后，访问 http://localhost:8000 即可体验上传和访问文件。记得先在 static/ 目录下放个 example.txt 文件。

1. 痛点场景：你是在“单线程”思考吗？

想象你正在开发一个爬虫程序，需要下载 100 张高清图片。

如果你用传统的 requests 库，代码逻辑通常是这样的：

发起请求 A -> 等待网络响应（500ms） -> 保存图片 A。

发起请求 B -> 等待网络响应（500ms） -> 保存图片 B。

...以此类推。

问题出在哪里？在那 500ms 的网络等待时间里，你的 CPU 实际上在摸鱼！它明明可以处理剩下的 99 个请求，却非要死等这一个响应回来。这种模式叫“同步阻塞”，是导致程序运行缓慢的头号元凶。

解决方案：asyncio。它让 Python 学会了“分身术”，在等待 A 的时候，顺手把 B、C、D 全都发出去。

2. 概念拆解：米其林餐厅的秘密

生活化类比

为了理解 asyncio，我们把 CPU 比作餐厅厨师。

同步阻塞（Synchronous）：厨师把牛排丢进锅里，然后死死盯着锅，直到肉熟了才去切土豆。这时候，哪怕外面排了 10 个客人，厨师也什么都不干。

异步非阻塞（Asyncio）：厨师把牛排丢进锅里，定个闹钟（注册事件），转身就去切土豆或准备酱汁。等闹钟响了，他再回来翻牛排。

在这个比喻中：

事件循环 (Event Loop)：就是那个“闹钟管理器”。它负责监控哪些任务做好了，该切回哪一环。

协程 (Coroutine)：就是“牛排煎制”或“切土豆”这些可以中途挂起、之后再继续的任务。

3. 动手实战：从 Hello World 到并发请求

基础代码

import asyncio
import time

# 定义一个协程函数（使用 async 关键字）
async def fetch_data(id, delay):
    print(f"任务 {id}: 正在发起请求，预计耗时 {delay} 秒...")
    # 使用 await 挂起当前任务，模拟网络 I/O
    await asyncio.sleep(delay) 
    print(f"任务 {id}: 数据返回成功！")
    return f"结果 {id}"

async def main():
    start_time = time.perf_counter()

    # 创建任务并发执行
    print("--- 任务开始 ---")
    results = await asyncio.gather(
        fetch_data(1, 3),
        fetch_data(2, 1),
        fetch_data(3, 2)
    )

    end_time = time.perf_counter()
    print(f"--- 所有任务完成，总耗时: {end_time - start_time:.2f} 秒 ---")
    print(f"返回列表: {results}")

# 运行事件循环
if __name__ == "__main__":
    asyncio.run(main())

代码解析

• async def: 告诉 Python 这是一个协程，调用它不会立即执行，而是返回一个协程对象。
• await: 这是“暂停键”。它告诉事件循环：“我要在这儿等一会儿，你先去处理别人，等好了再叫我。”
• asyncio.gather: 这是“集合指令”，它把多个协程打包，让事件循环同时启动它们。
• 结果分析: 虽然总等待时间是 3+1+2=6 秒，但你会发现程序运行只需 3 秒左右。因为最长的那个任务还没做完时，短的任务已经利用空隙做完了。

4. 进阶深潜：新手最容易掉进去的坑

常见陷阱：在异步代码里写同步阻塞

很多新手会写出这样的代码：

async def broken_coroutine():
    time.sleep(5) # 致命错误！
    await some_async_func()

后果：time.sleep(5) 会让整个线程停摆 5 秒。哪怕你有 1000 个协程，它们都会被这一行代码活生生卡死。在异步世界里，必须使用 await asyncio.sleep()。

最佳实践

• 不要为了异步而异步：如果你的任务是计算密集型的（如：大矩阵运算、视频转码），asyncio 帮不了你，你应该用 multiprocessing（多进程）。
• 库的选择：传统的 requests 或 pymysql 是同步的，在 asyncio 中会失效。请使用对应的异步版本，如 aiohttp。

一、Maven依赖引入

1. Netty-WebSocket-Spring-Boot-Starter

<dependency>
    <groupId>org.yeauty</groupId>
    <artifactId>netty-websocket-spring-boot-starter</artifactId>
    <version>0.13.0</version> <!-- 请使用最新版本 -->
</dependency>

2. Spring官方WebSocket Starter

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-websocket</artifactId>
</dependency>

二、核心差异对比

三、使用场景决策指南

✅ 选择 Netty-WebSocket 当：

• 需要处理高频实时数据：金融行情推送、物联网传感器数据
• 使用自定义二进制协议：游戏数据包、音视频流传输
• 追求极致性能：要求1万+并发连接，低延迟响应
• 脱离Servlet容器：希望WebSocket服务独立部署

✅ 选择 Spring官方Starter 当：

• 开发企业级消息系统：聊天应用、实时通知系统
• 需要完整STOMP支持：利用消息代理和订阅机制
• 快速集成Spring生态：与Security、Data等组件协作
• 兼容旧浏览器：需要SockJS回退支持

四、核心代码实现对比

方案1：Netty-WebSocket实现（实时数据推送）

@SpringBootApplication
@EnableNettyWebSocket // 启用Netty WebSocket服务器
public class DataPushApplication {
    public static void main(String[] args) {
        SpringApplication.run(DataPushApplication.class, args);
    }
}

/**
 * 实时数据推送处理器
 * 特点：直接操作Session，手动管理连接
 */
@ServerEndpoint(host = "0.0.0.0", port = "8080", path = "/realtime")
public class DataPushHandler {

    // 存储所有活动会话
    private static final Set<Session> sessions = ConcurrentHashMap.newKeySet();

    @OnOpen
    public void onOpen(Session session) {
        sessions.add(session);
        session.sendText("CONNECTED|" + LocalTime.now());
    }

    @OnText
    public void onText(Session session, String message) {
        // 处理文本消息（如控制指令）
        String response = processCommand(message);
        session.sendText(response);
    }

    @OnBinary
    public void onBinary(Session session, byte[] bytes) {
        // 解析二进制数据（如传感器数据）
        SensorData data = SensorDecoder.decode(bytes);
        // 处理数据逻辑...
        byte[] response = SensorEncoder.encode(data);
        session.sendBinary(response);
    }

    @OnClose
    public void onClose(Session session, CloseReason reason) {
        sessions.remove(session);
    }

    // 广播数据给所有客户端
    public static void broadcast(byte[] data) {
        sessions.forEach(session -> {
            if (session.isOpen()) {
                session.sendBinary(data);
            }
        });
    }
}

方案2：Spring官方Starter实现（完整聊天室）

/**
 * WebSocket配置类
 * 特点：使用STOMP协议，配置消息代理
 */
@Configuration
@EnableWebSocketMessageBroker
public class ChatConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        // 客户端连接端点
        registry.addEndpoint("/chat-ws")
                .setAllowedOriginPatterns("*")
                .withSockJS(); // 浏览器兼容支持
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        // 启用内存消息代理
        registry.enableSimpleBroker("/topic", "/queue");

        // 设置应用消息前缀
        registry.setApplicationDestinationPrefixes("/app");

        // 设置用户私有队列前缀
        registry.setUserDestinationPrefix("/user");
    }
}

/**
 * 聊天控制器
 * 特点：使用高级消息抽象，自动处理订阅
 */
@Controller
public class ChatController {

    @Autowired
    private SimpMessagingTemplate messagingTemplate;

    // 处理公共聊天消息
    @MessageMapping("/chat")
    @SendTo("/topic/messages")
    public ChatMessage handlePublicMessage(@Payload ChatMessage message, 
                                        Principal principal) {
        message.setSender(principal.getName());
        message.setTimestamp(LocalDateTime.now());
        return message;
    }

    // 处理私有消息
    @MessageMapping("/private")
    public void handlePrivateMessage(@Payload ChatMessage message, 
                                   Principal principal) {
        message.setSender(principal.getName());
        message.setTimestamp(LocalDateTime.now());

        // 定向发送给接收者
        messagingTemplate.convertAndSendToUser(
            message.getRecipient(), 
            "/queue/private", 
            message
        );
    }

    // 用户上线处理
    @EventListener
    public void handleConnect(SessionConnectedEvent event) {
        String username = event.getUser().getName();
        // 通知所有用户更新在线列表
        messagingTemplate.convertAndSend("/topic/onlineUsers", 
            userService.getOnlineUsers());
    }
}

/**
 * 消息实体类
 */
public class ChatMessage {
    private String sender;      // 发送者
    private String recipient;   // 接收者（私聊使用）
    private String content;     // 消息内容
    private LocalDateTime timestamp; // 时间戳

    // getters & setters
}

五、关键差异解析

1. 连接管理方式

   • Netty：手动维护Session集合，直接操作连接
   • Spring：自动管理连接，通过SimpMessagingTemplate发送消息

2. 消息处理模式

graph LR
A[客户端] --> B{Netty方案}
B --> C[直接处理二进制数据]
B --> D[自定义协议解析]

A --> E{Spring方案}
E --> F[STOMP消息代理]
E --> G[发布/订阅模式]

3. 异常处理机制

   • Netty：通过@OnError捕获异常，需手动关闭问题会话
   • Spring：全局异常处理器@MessageExceptionHandler统一处理

4. 集群支持

   • Netty：需自行实现分布式会话管理（如Redis）
   • Spring：天然支持通过消息代理（RabbitMQ/Redis）实现集群

六、选型建议总结

黄金实践法则：

新项目若不需要处理二进制协议，优先选择Spring官方方案；

现有系统需添加高性能实时通道，引入Netty作为独立服务模块；

关键业务系统建议同时实现两种方案，Netty处理实时数据流，Spring处理业务消息。

知识点：

1、Fuzz技术-用户口令-常规&模块&JS插件
2、Fuzz技术-目录文件-目录探针&文件探针
3、Fuzz技术-未知参数名-文件参数&隐藏参数
4、Fuzz技术-构造参数值-漏洞攻击恶意Payload

Fuzz：是一种基于黑盒的自动化软件模糊测试技术,简单的说一种懒惰且暴力的技术融合了常见的以及精心构建的数据文本进行网站、软件安全性测试。

Fuzz的核心思想:
口令Fuzz(弱口令)
目录Fuzz(漏洞点)
参数Fuzz(利用参数)
PayloadFuzz(Bypass)

Fuzz应用场景：
-爆破用户口令
-爆破敏感目录
-爆破文件地址
-爆破未知参数名
-Payload测漏洞（绕过等也可以用）
在实战黑盒中，目标有很多没有显示或其他工具扫描不到的文件或目录等，我们就可以通过大量的字典Fuzz找到的隐藏的文件进行测试。

一、Fuzz技术-用户口令-常规&模块&JS插件

1、无验证码密码明文

这种情况下爆破密码或者账号密码都爆破

只爆破密码很简单，这里不做演示

如果要同时爆破账号和密码，在Intruder模块需要选择Cluster bomb

2、无验证码密码弱加密（MD5）

密码使用MD5加密

在爆破的时候可以选择加密语言

3、无验证码密码复杂加密（通过js文件进行加密）

密码强加密，有自己的加密算法，需要我们去逆向出加密算法

此处加密算法逆向案例可以参考我的博客：https://www.cnblogs.com/Kurisu-Christina/p/19402512

该博文的演示案例二有说明

那么这种情况如何从burpsuite中发包呢？

使用插件BurpCrypto，将加密源码粘贴放入，并创建一个方法，传参数p为密码

二、Fuzz技术-目录文件-目录探针&文件探针

打开就是403的网站可以测试有没有其他目录

也可以使用工具来FUZZ

https://github.com/maurosoria/dirsearch

https://github.com/7kbstorm/7kbscan-WebPathBrute

三、Fuzz技术-未知参数名-文件参数&隐藏参数

当爆破出目录，再爆破出文件名后，有些文件是可以传参数的，这样不就造成漏洞了吗

试着爆破参数名：

忙猜这里参数名为do，我们可以给他传入其他参数值

四、Fuzz技术-构造参数值-漏洞攻击恶意Payload

忙猜这里参数名为do，我们可以给他传入其他参数值

有很多就执行成功了

爆破的地方有很多，包括提交方式，js文件等也可以爆破，不要把想法仅限于账号密码

五、SRC泄露未授权漏洞

Fuzz手机加验证码突破绕过

爆破手机号

Fuzz访问URL挖未授权访问

Fuzz密码组合规则信息泄露

为什么要了解虚拟机操作系统？

想象一下，你有一台物理电脑，但想在里面运行多个"虚拟电脑"，每个"虚拟电脑"都有自己独立的操作系统。这就是虚拟机！而选择哪个操作系统安装在虚拟机里，就像选择给不同的房间布置不同的装修风格。

对新手来说，了解这些系统能帮你：

• 找到最适合学习的系统
• 避免不必要的安装麻烦
• 快速上手实践

虚拟机操作系统简介

Rocky Linux

你可以把它看作是CentOS的"接班人"。CentOS官方支持已转向CentOS Stream，而Rocky Linux完美接替了原先CentOS的稳定位置。就像你习惯用的某个经典产品停产了，它的"官方继承者"出现了。

特点：

• 与CentOS几乎一样的使用体验
• 非常稳定，适合长期运行
• 社区活跃，资料越来越多

适合谁： 以前用过CentOS，或者需要稳定服务器环境的新手

CentOS 7（经典稳定版）

虽然"年纪"有点大了（2014年发布），但依然有很多教程和环境基于它。就像Windows 7虽然老了，但很多人还在用。

注意： 官方主流支持已结束，但还有部分扩展支持

适合谁：

• 跟着老教程学习的新手
• 运行特定老旧软件
• 只是想在虚拟机里"体验一下"的人

Ubuntu Server（新手友好之选）

如果你想找最容易上手的Linux服务器系统，这可能是最佳选择。它就像"智能手机"中的iPhone——开箱即用，设置简单，遇到问题一搜就有答案。

特点：

• 安装过程图形化，像安装普通软件
• 庞大的社区，海量中文教程
• 软件更新快，能用到最新技术

适合谁： 完全零基础，想快速上手Linux服务器的新手

Debian（稳定可靠之选）

如果说Ubuntu是"时尚快消品"，Debian就是"经典工艺品"。它不追求最新，但追求最稳定。很多企业服务器都使用它。

特点：

• 极其稳定，运行几个月不用重启
• 软件包管理优秀
• 安全性很好

适合谁： 希望系统稳定，不追求最新功能的学习者

🐉 openEuler（国产新星）

华为推出的开源系统，近年来发展迅速。如果你是IT相关专业，或者关注国产化技术，值得了解。

特点：

• 中文支持好
• 针对服务器优化
• 国内社区活跃

适合谁： 对国产技术感兴趣，或需要中文环境支持的新手

如何选择适合你的系统？

根据你的目标选择

• "我只想试试Linux是什么" → 选 Ubuntu Server，安装简单，跟着教程一步步来就行
• "我要学运维，以后找工作" → 新手从 Ubuntu Server 入门，然后学 Rocky Linux
• "我要搭建一个长期运行的个人网站/服务" → 选 Debian 或 Rocky Linux
• "我学校的教程/实验室用的都是CentOS 7" → 跟着学校走，用 CentOS 7
• "我想了解国产操作系统" → 选 openEuler

系统配置要求对比

所有系统的基本要求都差不多：

• 内存：至少2GB（4GB更流畅）
• 硬盘：20GB以上
• CPU：现代CPU都没问题

Ubuntu Server 对新手最友好，安装过程中会有很多提示和帮助。

最终建议： 从 Ubuntu Server 22.04 LTS 开始。它就像学开车时用的教练车——安全、友好、有辅助。等你熟悉了，再尝试其他系统，就知道它们的区别和特点了。

虚拟机操作系统的世界很广阔，但第一步总是最简单的：下载一个，装上试试。动手操作半小时，比看十篇教程都有用。

问题背景

做一个数据库表查看、标注与分析的工具软件。Table是数据库中表的信息（information_schema.tables）；Documentation是Table的数据字典文档，存储在本地文件中；Annotation是对Table的额外标注信息，存储在另一个数据库中。每一条Table，最多关联到一条Documentation和一条Annotation。

现在想搜索Table。前端向后端提供3个参数，搜索关键词列表、当前页码、每页条数；后端的搜索逻辑是，如果一条完整数据（Table+Documentation+Annotation）包含所有搜索关键词，则将Table加入搜索结果中。

Table的数量目前为6000+，要做到秒级搜索。

初步实现

因为跨数据源，所以不能简单连表查询。

对于每个Table，查出Documentation、Annotation，然后将Table、Documentation、Annotation中要搜索的字段值取出来，用空格隔开拼接为字符串，形如"Table字段值 Documentation字段值 Annotation字段值"，我们称之为SearchKey（搜索键）。如果每个关键词都包含在SearchKey中，则将Table加入搜索结果。

搜索时，先获取所有Table，然后遍历每个Table，获取SearchKey并判断是否加入搜索结果。

为了提高速度，用Redis缓存SearchKey。

分析数据情况：

• Table只增、不删、不改，因此，搜索时要重新获取所有Table，确保搜索到新Table；不必考虑驱逐（evict）SearchKey的缓存。
• Documentation不增、不删、不改，因此，不必考虑驱逐SearchKey的缓存。
• Annotation增、删、改，因此，要在Annotation增删改之后驱逐对应SearchKey的缓存，确保搜索到Annotation的最新信息。

实测结果：

• 实现了功能，支持同时按Table、Documentation、Annotation的字段搜索。
• 有性能问题，即使缓存已经全部完成，但每次搜索都要耗时30s左右，原因是6000+个Table遍历从Redis获取SearchKey，每次耗时1~15ms，累计耗时非常长。

第一次性能优化

优化缓存策略。

获取所有Table后，构建SearchKeyMap（Table→SearchKey），然后将SearchKeyMap缓存，这样，下一次搜索时，只需要从Redis获取一次，提高传输效率。

为了确保搜索到新Table，缓存SearchKeyMap时将Table列表的长度作为缓存键，如果新增了Table，则SearchKeyMap不会命中缓存，而是重新构建。

为了减少构建SearchKeyMap的时间，仍然保留单个SearchKey的缓存，仍然在Annotation增删改之后驱逐单个SearchKey的缓存，但不同的是，还要同时驱逐SearchKeyMap的缓存。

实测结果：

• 性能提升明显，在缓存全部完成的情况下，搜索耗时降至1.3s左右。
• 仍然有性能问题，对一个Annotation做了增删改，会驱逐整个SearchKeyMap缓存，重建SearchKeyMap就又回到了遍历Table的情况，仍然要耗时30s左右。

第二次性能优化

优化缓存策略。

取消单个SearchKey的缓存，只缓存SearchKeyMap。

搜索Table时，要获取SearchKeyMap。先获取现有的SearchKeyMap缓存（固定缓存键，不再使用列表长度作为缓存键；没有缓存则取得空Map），然后遍历Table，如果Table不在SearchKeyMap中，则计算SearchKey并放入SearchKeyMap。这样，第一次搜索时会计算每个Table的SearchKey，后续搜索就只需要计算新Table的SearchKey。

Annotation增删改后，要更新SearchKeyMap。先获取现有的SearchKeyMap缓存，然后重新计算指定Table的SearchKey并放入SearchKeyMap。这样，无需每次都重建整个SearchKeyMap。

实测结果：Annotation增删改后再搜索，耗时降至1.3s左右。

第三次性能优化

优化缓存实现方式。

既然现在只需要简单地缓存一个SearchKeyMap，那么不一定要用Redis。

使用Redis作为缓存（RedisCacheManager），虽然内网通信快，但仍有网络开销。实测平均1092.9ms。

使用Map作为缓存（ConcurrentMapCacheManager），其他代码完全不变。实测平均968.3ms。

修改代码，直接用类中的Map字段作为缓存，省去缓存管理器的开销。实测平均915.2ms。

可见，性能有提升，但幅度不大。由于软件在开发中，要频繁重新运行，Redis能保持缓存，Map不能，因此保持上一版方案不做修改。

第四次性能优化

第三次优化其实是盲目的，应该要用事实找出性能瓶颈。

对搜索过程计时分析发现，一次耗时1105ms的搜索，其中获取所有Table耗时1028ms，占比93%，是绝对的性能瓶颈。

思路1：先只获取所有表名，而不是Table对象，如果表名对应的SearchKey匹配，再获取Table。实测发现，如果匹配的表名很多（例如关键词列表为空时），则即使有表名→Table的缓存（Redis实现），逐个获取也远远慢于直接从数据库一次性获取。因此，此思路不可行。

思路2：Table只增、不删、不改，因此可以考虑增量获取。缓存Table列表，每次获取时跳过缓存的长度，只获取增量部分。然而，information_schema.tables中没有id，无法保证新Table一定排在最后。因此，此思路不可行。

思路3：获取所有Table说到底只是为了搜索到新Table，如果能知道什么时候新增了Table，就可以放心地使用Table列表的缓存，或者从数据库重新获取。那么怎么知道？由于Table只增，所以可以用Table的数量判断。缓存Table列表，每次先从数据库查出数量（比直接查出Table列表明显更快），如果数量与缓存一致，则用缓存，否则查库。实测，此思路可行。

实现思路3后，再次计时分析。无新增Table时，搜索耗时降至360ms左右（只查库数量）；有新增时，耗时升至1.5s左右（查库数量+列表）。由于搜索Table的频率远远高于新增Table，因此，总体性能提升显著。

总结

经过数次性能优化，在满足功能的前提下，搜索时间从30s左右降至稳定0.4s左右，效果显著。0.4s已经没有缓慢感，性能优化工作可以结束了。

从上述优化过程可见，做优化要因地制宜，具体问题具体分析，选择合适的策略；优化效果的衡量要以实测结果为准。

在 H5 页面中跳转到其他 APP，可以使用以下几种方式：

1. URL Scheme（自定义协议）

许多 APP 都支持 URL Scheme 方式的跳转，例如：

<a href="weixin://">打开微信</a>
<a href="alipay://">打开支付宝</a>
<a href="yourapp://path">打开自定义 APP</a>

注意：

• 需要目标 APP 支持 URL Scheme，未安装 APP 时会无响应或报错。
• 在 iOS 9+ 之后，需在 info.plist 中配置 LSApplicationQueriesSchemes。

2. Universal Links（iOS）& Deep Link（Android）

Universal Links（iOS）和 Deep Link（Android）可以更安全地跳转到 APP，且未安装时可跳转至 Web 页面。

• 需要服务端配置特定文件（如 apple-app-site-association）。
• 适用于 iOS 9+，不会弹出确认框，用户体验更好。

示例：

<a href="https://yourdomain.com/path">打开 APP</a>

3. Intent Scheme（Android 专属）

在 Android 设备上可以使用 intent:// 方案：

<a href="intent://path#Intent;scheme=yourapp;package=com.example.app;end;"
  >打开 APP</a>

• 若 APP 已安装，则直接打开。
• 若 APP 未安装，则可跳转到 Google Play。

4. iframe 方式（部分浏览器支持）

<iframe src="yourapp://path" style="display: none;"></iframe>

• 可用于尝试静默拉起 APP，但可能被浏览器拦截。

5. 混合方式（兼容性方案）

综合以上方法，推荐使用 JS 处理：

<script>
  function openApp() {
    var schemeUrl = "yourapp://path";
    var storeUrl = "https://yourapp.com/download"; // APP 下载地址

    var ua = navigator.userAgent.toLowerCase();
    var isAndroid = ua.indexOf("android") > -1;
    var isIOS = ua.indexOf("iphone") > -1 || ua.indexOf("ipad") > -1;

    if (isIOS) {
      window.location.href = schemeUrl;
      setTimeout(() => {
        window.location.href = storeUrl;
      }, 2000);
    } else if (isAndroid) {
      window.location.href = schemeUrl;
      setTimeout(() => {
        window.location.href = storeUrl;
      }, 2000);
    } else {
      window.location.href = storeUrl;
    }
  }
</script>

<button onclick="openApp()">打开 APP</button>

总结

如果 APP 需要兼容性更好的跳转方式，建议结合 Universal Links（iOS）和 Deep Link（Android）。