流量数据样本管理系统，这个项目名第一次看到的时候，我第一反应是“这不就是个带文件上传的CRUD后台吗”。等真正动手做起来才发现，样本数据的组织方式、检索效率、文件存储策略，每一项都有不少坑。当时团队里接了一批网络流量抓包样本，PCAP文件丢在共享目录里，谁要用数据就去翻文件夹，Excel记的分类信息跟文件对不上，时间一长根本分不清某条样本是从哪个任务来的、有没有打过标签、是不是跟别的样本重复。就是因为这个痛点，才决定从零搭一套基于Vue和Spring Boot的流量样本管理系统，把文件的元数据、标签、分类、检索、统计全部沉淀成一个可用的内部平台。

这套系统说白了就是流量样本的“档案馆加检索台”。它解决的核心问题有三个：一是把PCAP等样本文件的元数据结构化入库，让每条样本都有据可查；二是把海量文件从分散的目录收拢到统一存储，通过Web界面就能完成上传、下载和批量导入；三是在元数据基础上做组合检索与统计，比如按协议类型、源IP、时间段、标签组合筛选，按天或按协议看样本分布，方便支撑算法标注和分析任务。无论你是做安全分析、流量溯源，还是学校实验室里管理教学数据集，这套设计思路都能直接套用。下面我把整个复盘拆成六个部分，从需求拆解讲到部署排障，都是实测过的经验，照着走基本能落地。

1. 项目全貌与核心功能拆解

1.1 流量样本数据到底要管什么

在做功能清单之前，我得先理清一件事：一条流量样本数据，在系统里到底长什么样。很多做管理系统的人上来就建表，结果字段设计得一塌糊涂。其实一条流量样本可以拆成两层来看，一层是文件本身，也就是那个PCAP或者cap格式的抓包文件，它可能有几十MB甚至几百MB，没法直接塞进数据库的字段里；另一层是文件的元数据，包括协议类型、源目IP、端口、包数量、捕获时间、文件大小、来源任务、标签、备注说明等，这些信息是结构化的，可以也必须在数据库里管理。

所以系统设计的第一个关键决策就是把“文件存储”和“元数据管理”分开。数据库只存样本的描述信息和文件路径，实际文件落到服务器磁盘的指定目录。这么做的好处非常明显，数据库不会因为大文件变臃肿，备份和迁移也更方便，查列表、做统计时不会拖出来一大堆二进制数据。至于文件会不会跟元数据脱节，靠一条唯一的文件路径字段和MD5校验值来保证可追溯。

管好元数据只是第一步，第二件事是标签和分类体系。流量样本的价值不光在于文件本身，还在于它被怎么标注。比如一条样本是正常业务流量还是恶意流量，属于哪一类攻击行为，是C2通信还是端口扫描，这些标注字段直接影响后续分析。我见过很多团队把标签写在文件名里，比如“attack_dns_20241101.pcap”，这种做法文件一多就崩盘。正确的做法是把标签做成独立的字段或关联表，让一条样本可以打多个标签，支持组合检索，这样后续做数据分析时才能按标签批量筛选数据。

1.2 功能清单与业务场景

整个系统的功能模块我拆成了六块，每一块都对应一个具体的业务场景，不是凭空想出来的功能。

这套功能做下来，覆盖了一个很典型的闭环：采集人员把抓包文件上传并填写元数据，标注人员给样本打标签、分类，分析人员按条件检索并下载样本做检测研究，管理员实时掌握整个样本库的健康状态。我在开发过程中发现，批量导入这个功能虽然不起眼，但实际使用频率极高，因为大部分历史样本都是Excel记录的，没有这个入口，系统上线初期根本填不满数据，所以这块值得多花心思。

2. 技术选型背后的逻辑

2.1 前端为什么选Vue而不是别的

前端框架这个选择题，其实没有标准答案，只有适不适合团队和场景。当时我们团队对Vue的熟悉度最高，加上项目里的页面主要是表格、表单、弹窗、图表这类中后台界面，Vue配合Element UI确实是最顺手的组合。尤其是表格加弹窗这种模式，Element UI已经封装得非常完整，分页表格、表单校验、上传组件开箱即用，省下的时间不是一星半点。

我后来在实际开发里体会更深的是Vue的响应式机制，它让列表数据、搜索条件、loading状态、选中项之间的联动非常自然。比如用户选中了几行样本准备批量删除，删除完成后表格自动刷新，选中项自动清空，这些逻辑如果放在传统的jQuery时代，要写不少手动操作DOM的代码，在Vue里只需要改动数据源和状态就好了。组件化也让代码结构更清楚，我把列表页拆成了搜索区、工具栏、表格区、分页区四个子组件，每个组件只负责自己的事，后面加功能时只需要往对应组件里塞内容，不会把单个文件写得越来越膨胀。

至于用Vue 2还是Vue 3，我的建议是根据团队的熟悉程度来定。新项目用Vue 3加Element Plus是趋势，但如果团队之前都是Vue 2写的老代码，用Vue 2加Element UI反而上手更快，迁移成本低。这个项目里我用的Vue 2，因为相关的模板、组件生态更成熟，网上踩坑资料也多，等有小版本升级需要时再平滑过渡。

2.2 后端Spring Boot带来的确定性

后端用Spring Boot的理由其实比前端更质朴：背靠Java生态，文档多、排障资料多，招人也好招。Spring Boot的自动配置和Starter机制让项目从零启动变得很快，一个依赖引入、一段配置搞定数据库连接，前后端接口对接可以快速跑起来。对于这种业务逻辑相对标准的内部管理系统，Spring Boot的MVC三层结构简直就是量身定做，Controller负责接口接收参数返回结果，Service写业务逻辑，Mapper负责数据库交互，代码结构清楚，连新人都能很快上手维护。

当时也纠结过要不要用Node.js或者Python写后端，毕竟团队里也有人会。但考虑到这个系统后续可能会接更复杂的数据处理任务，比如调起一些Java生态里的分析库，或者跟团队已有的Java微服务打通，Spring Boot的长期优势更明显。别以为管理系统就没有并发压力，一旦批量导入几千条数据和并发上传大文件，Java的成熟线程模型和连接池机制能扛住，相对冷门的方案在这一块就得自己踩坑。

另外，Spring Boot的拦截器、过滤器机制在权限控制上很好用。我用一个简单的HandlerInterceptor做登录校验，判断请求头里的Token，配合一个ThreadLocal保存当前登录用户信息，接口层要拿操作人时直接调一个静态方法，非常方便。这套轻量的方案比引入整套Spring Security要快得多，也完全够用。

2.3 数据库与文件存储的分工

数据存储这块，我的核心原则是“谁适合存什么就存什么”。样本的标题、时间、IP、标签这些结构化信息毫无疑问放MySQL，用MyBatis Plus做持久层。文件本身放服务器文件系统或对象存储，数据库里只记录存储路径。很多初学者会把文件转成二进制存到数据库的BLOB字段里，小文件时确实方便，但流量样本零散且体积大，SQL查询性能会随着文件混杂进来急剧下降，备份时也会痛苦不堪。

目录组织上，我建议按年份和任务批次来分，比如/data/samples/2024/11/20241115_xxx.pcap，文件名里带上日期和批次标识，同时在数据库里维护MD5字段。MD5这个字段我强烈建议保留，不只是为了去重，更是为了后续排查问题时确认文件有没有被篡改或损坏，做数据合规审计时也说得清。

数据库连接层用MyBatis Plus还有一个好处，它自带的QueryWrapper能大幅简化动态条件查询代码。以前用MyBatis写动态SQL要拼接XML，条件一多就看着头大，用QueryWrapper之后，代码逻辑变成了Java代码里直接链式构建查询条件，条件为空就自动忽略，这跟多条件检索页的需求完美契合。后面我会把这段代码展示出来，照着抄就能用。

3. 数据库设计与核心表结构

3.1 核心表拆分逻辑

很多管理系统的表设计败在“一张表管所有事”。我这个系统一开始就把表拆分得相对清楚，一共四张核心表：

• 用户表（sys_user）：存账号、密码、昵称、角色、状态。
• 样本分类表（sample_category）：存样本类别名称，方便下拉选择。
• 样本信息表（sample_info）：存流量样本的元数据和文件路径。
• 操作日志表（operation_log）：记录用户的关键操作，方便审计排查。

分类表单独拆出来，不是为了显得设计复杂，而是为了避免在样本表里写死“恶意流量”“正常流量”这种字符串。字符串飘在数据里，一旦想改分类名，就要UPDATE一大片数据。做成关联表之后，分类名发生变化只需改一行，样本表里存一个分类ID就好。下拉框的数据也从分类表动态查，新增分类不需要改前端代码。

3.2 样本信息表的字段设计

样本信息表是这个系统的核心，字段设计直接影响后续检索和分析功能好不好用。我最终定下来并实践过的字段如下：

设计里有两个容易被忽略的细节。一是IP地址用varchar存，不要用int或者binary，虽然存储上会多占一点空间，但对管理系统的查询来说，用户习惯直接输入“192.168.1.1”这种字符串，数据库里存字符串可以让LIKE模糊查询无缝衔接。二是tag_list用逗号分隔字符串，而不是单独建一张标签关联表。标签如果要做复杂的统计或者动态维护，建议拆表，但当前场景只要支持按标签模糊检索即可，一张字符串字段足够，还省了联表查询的麻烦。

3.3 建表SQL与索引设计

建表SQL我简化后贴出来，核心字段和索引都在。在建表这条路上我踩过的最大教训是：别急着把所有字段都建索引，索引多了写入和存储压力都上去，索引少了查询又慢。中等规模数据量下，表格里的三个索引就够覆盖绝大多数查询场景。

CREATE TABLE `sample_info` ( `id` bigint NOT NULL AUTO_INCREMENT, `sample_name` varchar(128) DEFAULT NULL, `protocol_type` varchar(32) DEFAULT NULL, `src_ip` varchar(64) DEFAULT NULL, `src_port` int DEFAULT NULL, `dst_ip` varchar(64) DEFAULT NULL, `dst_port` int DEFAULT NULL, `packet_count` int DEFAULT NULL, `file_size` bigint DEFAULT NULL, `capture_time` datetime DEFAULT NULL, `file_path` varchar(255) DEFAULT NULL, `file_md5` varchar(64) DEFAULT NULL, `category_id` bigint DEFAULT NULL, `tag_list` varchar(255) DEFAULT NULL, `description` text, `status` tinyint DEFAULT '1', `upload_user_id` bigint DEFAULT NULL, `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_time` (`capture_time`), KEY `idx_proto_srcip` (`protocol_type`, `src_ip`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

索引设计思路是这样的：idx_time针对时间范围查询，比如看某个月的数据，时间段条件是最常用的。idx_proto_srcip是一个组合索引，针对“协议类型+源IP”这种联合筛选，因为检索时最常见的操作就是查某个协议的样本，或者查某个IP在什么协议下出现过。idx_category则服务分类统计。字段顺序也有讲究，把区分度高的protocol_type放前面，能更快缩小范围。

提示：如果你们的数据量真的涨到了百万级，建议把tag_list拆出来用关联表，同时给description建立全文索引或者改用搜索引擎，否则LIKE '%xxx%'会全表扫描拖慢查询。但停留在内部管理系统级别，目前的表结构完全够用，别过度设计。

4. 后端关键模块实现

4.1 三层架构与基础代码骨架

后端的包结构我保持最标准的Controller-Service-Mapper三层。Controller不写业务，只接收参数、调Service、返回统一结果；Service层放业务逻辑；Mapper层用MyBatis Plus的BaseMapper，大部分单表操作不用写SQL。给出一个最简单的分层示例，大家一眼就能看懂。

// 统一返回结果 public class Result<T> { private Integer code; private String message; private T data; // getter/setter省略 } // 实体类对应的Mapper public interface SampleInfoMapper extends BaseMapper<SampleInfo> { } // Service接口与实现 public interface SampleInfoService extends IService<SampleInfo> { IPage<SampleInfo> searchSample(SampleQueryDTO dto, Page<SampleInfo> page); } @Service public class SampleInfoServiceImpl extends ServiceImpl<SampleInfoMapper, SampleInfo> implements SampleInfoService { @Override public IPage<SampleInfo> searchSample(SampleQueryDTO dto, Page<SampleInfo> page) { // 查询逻辑见下一节 } } // Controller @RestController @RequestMapping("/api/sample") public class SampleInfoController { @Autowired private SampleInfoService sampleInfoService; @PostMapping("/page") public Result<IPage<SampleInfo>> page(@RequestBody SampleQueryDTO dto) { Page<SampleInfo> page = new Page<>(dto.getPageNum(), dto.getPageSize()); return Result.ok(sampleInfoService.searchSample(dto, page)); } }

代码结构简单到没什么可吹的，但它在实际开发中的价值是，后来加“下载记录”功能和“操作审计”功能时，我只是在对应层里追加方法，改动范围非常收敛，不会出现改一行代码却要翻三个文件找位置的情况。管理系统最怕的不是需求多，而是逻辑到处飞，分层就是为了把“到处飞”变成“各回各家”。

4.2 多条件组合查询的实现

多条件查询是这个系统的灵魂功能。前端搜索区常有协议类型下拉框、源IP输入框、目的IP输入框、时间范围选择器、标签输入框、分类下拉框。这些条件每个都可能为空，查询时必须动态拼SQL。MyBatis Plus的QueryWrapper让这种动态条件特别干净。

@Override public IPage<SampleInfo> searchSample(SampleQueryDTO dto, Page<SampleInfo> page) { LambdaQueryWrapper<SampleInfo> wrapper = Wrappers.lambdaQuery(); // 协议类型不为空才加入条件 wrapper.eq(StringUtils.hasText(dto.getProtocolType()), SampleInfo::getProtocolType, dto.getProtocolType()); // 源IP使用模糊匹配，兼容输入完整IP或IP段 wrapper.like(StringUtils.hasText(dto.getSrcIp()), SampleInfo::getSrcIp, dto.getSrcIp()); // 目的IP同样模糊匹配 wrapper.like(StringUtils.hasText(dto.getDstIp()), SampleInfo::getDstIp, dto.getDstIp()); // 分类ID精确匹配 wrapper.eq(dto.getCategoryId() != null, SampleInfo::getCategoryId, dto.getCategoryId()); // 标签模糊匹配 wrapper.like(StringUtils.hasText(dto.getTag()), SampleInfo::getTagList, dto.getTag()); // 时间是范围查询，用ge和le组合 if (dto.getStartTime() != null) { wrapper.ge(SampleInfo::getCaptureTime, dto.getStartTime()); } if (dto.getEndTime() != null) { wrapper.le(SampleInfo::getCaptureTime, dto.getEndTime()); } // 按捕获时间倒序，最新数据排前面 wrapper.orderByDesc(SampleInfo::getCaptureTime); return sampleInfoMapper.selectPage(page, wrapper); }

这段代码的关键在于eq/like方法的第一个参数是布尔值，条件不成立时该行查询条件就不会拼进SQL。这样前端传不传参数都无所谓，后端永远稳。我刚开始做的时候会把条件一个个用if包起来，代码又臭又长，换成这种写法后一眼就能看全所有查询分支。查询接口写好后，前端表格传一个JSON对象，里面包含所有查询字段，后端无脑接住就行。

4.3 文件上传下载的实现

文件上传是老生常谈，但流量样本文件有一个特点：体积大，动不动几百MB。Spring Boot里处理上传文件，需要先调整两个配置，一个是HTTP请求体大小限制，一个是单个文件大小限制。下面的配置给的是我调好的可用值：

spring: servlet: multipart: max-file-size: 1024MB max-request-size: 1024MB

上传接口的代码逻辑很简单，核心就是把MultipartFile保存到指定目录，文件名用UUID加原始后缀，避免重名把文件覆盖了。同时计算文件的MD5，这个值一方面用于去重，另一方面也为了完整性校验。

@PostMapping("/upload") public Result<Long> upload(@RequestParam("file") MultipartFile file, @RequestParam("sampleName") String sampleName) { String originalFilename = file.getOriginalFilename(); String suffix = originalFilename.substring(originalFilename.lastIndexOf(".")); String newFileName = UUID.randomUUID().toString().replace("-", "") + suffix; String dateDir = new SimpleDateFormat("yyyy/MM").format(new Date()); String relativePath = "/data/samples/" + dateDir + "/" + newFileName; File dest = new File(relativePath); if (!dest.getParentFile().exists()) { dest.getParentFile().mkdirs(); } file.transferTo(dest); // 计算并记录MD5，代码略，用DigestUtils即可 SampleInfo info = new SampleInfo(); info.setSampleName(sampleName); info.setFilePath(relativePath); info.setFileSize(file.getSize()); info.setFileMd5(md5Value); info.setCreateTime(new Date()); sampleInfoService.save(info); return Result.ok(info.getId()); }

下载接口更直接，用Spring的Resource加载文件所在路径，然后通过HttpServletResponse把文件写出去。需要注意的一个问题是，Nginx反代时如果文件超过一定大小，Nginx默认的客户端请求体大小限制也会生效，需要在Nginx配置里加client_max_body_size 1024m;，我最初部署时漏掉这一项，文件稍微大一点就报413，排查了半天才发现是这一层的问题。

4.4 数据统计接口

统计功能是给前端图表提供数据的。最常见的是按协议类型分组统计样本数量，以及按天统计新增样本量。这两类统计在MySQL里用GROUP BY加COUNT就能搞定，没太多花活。

@GetMapping("/statistics/protocol") public Result<List<Map<String, Object>>> protocolStat() { // 按protocol_type分组，统计每个协议的样本数 QueryWrapper<SampleInfo> wrapper = new QueryWrapper<>(); wrapper.select("protocol_type as name, count(*) as value"); wrapper.groupBy("protocol_type"); return Result.ok(sampleInfoMapper.selectMaps(wrapper)); } @GetMapping("/statistics/trend") public Result<List<Map<String, Object>>> trendStat() { // 按天统计样本数量，日期格式化为yyyy-MM-dd QueryWrapper<SampleInfo> wrapper = new QueryWrapper<>(); wrapper.select("DATE_FORMAT(capture_time, '%Y-%m-%d') as date, count(*) as count"); wrapper.groupBy("date"); wrapper.orderByAsc("date"); return Result.ok(sampleInfoMapper.selectMaps(wrapper)); }

这里我踩过一个不大不小的坑：groupBy("date")里如果直接写成中文字段别名，个别数据库版本会报语法错误，后来统一把别名改成简单的英文就稳定了。统计接口给前端返回的最好多是Map列表，前端ECharts直接绑定就行，不用再做二次转换。如果数据量大到GROUP BY撑不住，再考虑把统计结果缓存进Redis或者单独建一张统计表，但以内部样本库的量级，暂时用不上。

5. 前端页面与交互实现

5.1 前端工程结构与开发联调

前端我用Vue脚手架初始化项目，目录就是标准结构：src/api放接口封装，src/components放通用组件，src/views放页面级组件，src/router放路由，src/utils放公共方法。项目里我给每个模块都单独写了一个API文件，比如api/sample.js，把所有跟样本相关的请求集中管理，页面里只需要引入模块函数，不直接写axios调用。

开发联调阶段，最省心的方案是在vue.config.js里配置代理。前端开发服务器跑在8080端口，后端接口跑在8081端口，直接用代理把接口请求转发过去，避免跨域问题：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } } };

注意这里changeOrigin必须设为true，否则请求到达后端时Host头还是前端的域名，一些严格校验Host的组件可能反回异常。配好代理后，前端代码里所有请求都以/api开头，开发环境和生产环境无需大改，只需要生产环境用Nginx再配一次反向代理就行。

5.2 样本列表页开发

列表页是系统的门面，我的排版很固定：顶部一行搜索区，下面一行操作按钮，中间是表格，底部是分页器。搜索区用el-form加inline布局，放一个协议类型下拉框、两个IP输入框、一个时间范围选择器、一个标签输入框，再加一个“搜索”按钮和一个“重置”按钮。表格用el-table，列配置对应后端返回的字段，最后一列放操作按钮——编辑、查看详情、删除。

核心交互逻辑都在handleSearch方法里。用户点搜索时，把表单里的查询条件组装成对象，一次性发给后端：

async handleSearch() { this.queryParams = { protocolType: this.searchForm.protocolType, srcIp: this.searchForm.srcIp, dstIp: this.searchForm.dstIp, tag: this.searchForm.tag, startTime: this.searchForm.timeRange ? this.searchForm.timeRange[0] : null, endTime: this.searchForm.timeRange ? this.searchForm.timeRange[1] : null, pageNum: this.currentPage, pageSize: this.pageSize }; await this.fetchData(); }, async fetchData() { this.loading = true; try { const res = await getSamplePage(this.queryParams); this.tableData = res.data.records; this.total = res.data.total; } finally { this.loading = false; } }

列表页还有一个容易忽视的细节，就是表格里长字段的展示。file_path、description、tag_list如果直接放在表格里会撑爆布局，我的做法是用el-tooltip包裹，只展示缩略文本，鼠标放上去才显示完整内容。文件大小字段也从字节数格式化成了易读的MB单位，这样不用给用户增加无意义的换算负担。

5.3 新增与编辑表单

新增和编辑我共用一个el-dialog弹窗组件，弹窗里放一个el-form。表单字段跟数据结构基本一一对应，但校验规则要用心设一下。sampleName必填，协议类型必选，源IP、目的IP如果填了要校验格式，captureTime必填时间。Element Plus的校验规则用rules绑定，代码清爽：

rules: { sampleName: [{ required: true, message: '样本名称不能为空', trigger: 'blur' }], protocolType: [{ required: true, message: '请选择协议类型', trigger: 'change' }], captureTime: [{ required: true, message: '请选择捕获时间', trigger: 'change' }], srcIp: [{ pattern: /^(\d{1,3}\.){3}\d{1,3}$/, message: 'IP格式不正确', trigger: 'blur' }] }

编辑时的一个细节是回显。后端返回的数据里可能把captureTime格式化成字符串了，弹窗在打开时需要把它转成日期对象，否则时间选择器校验会报错。我在openEditDialog方法里做了转换：this.form.captureTime = row.captureTime ? new Date(row.captureTime) : null。这个问题看起来很基础，但不注意的话，每次点编辑都弹一个校验错误，体验非常差。

5.4 统计页与图表

统计页的核心是两张图：一张按协议分布的饼图，一张按天新增量的折线图。前端引入ECharts后，直接在mounted里调统计接口，拿到数据后塞进option：

async loadProtocolChart() { const res = await getProtocolStat(); const chart = echarts.init(this.$refs.protocolChart); chart.setOption({ tooltip: { trigger: 'item' }, series: [{ type: 'pie', data: res.data }] }); }

需要提醒的是，图表容器必须有明确的宽高，否则ECharts初始化出来是一张空白图。这个问题我第一次写时遇到过，后来给图表容器统一加了一个height: 400px的内联样式。另外，页面离开或数据刷新时要调用chart.dispose()释放实例，不然在多个弹窗或者路由切换时会存在内存泄漏的隐患。统计页虽然代码量不大，但它让整个系统分析人员的印象分直接提升一大截。

6. 部署上线与常见问题排查

6.1 前后端联调与问题定位

开发环境正常后，联调阶段最容易出问题的是接口参数不匹配。建议前后端先约定好JSON格式，我一般会把接口文档抽象成简单的字段对照表：前端传什么，后端返回什么，哪个字段可能为空。具体联调时，先打开浏览器Network面板，看看请求体和返回体，80%的问题一眼就能定位。比如前端传了pageNum和pageSize，后端却接收不到，大多是因为前端用params传参、后端用@RequestBody接收，参数位置不一致导致。

联调时还有一类高频问题：后端返回的数据格式是Result包装过的，前端拿不到data。这种情况务必盯着返回体的code字段，如果code不是200，前端要统一做一个全局的message提示，把后端的错误信息暴露出来，不然用户只会看到表格里啥都没有，不知道是接口报错还是真的没数据。我给axios封装了一个统一的响应拦截器，非200状态自动弹错误消息，省了不少事。

6.2 生产部署的Nginx配置

生产环境我采用前后端分离部署：前端构建后产出dist目录，交给Nginx托管静态文件；后端打成jar包运行在8081端口。Nginx需要配两个关键点：一是把前端请求转发给后端，二是调整上传文件大小限制。

server { listen 80; server_name sample.local; # 前端页面 root /var/www/sample-front/dist; index index.html; # 前端路由是history模式，必须做try_files，否则刷新404 location / { try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 大文件上传限制 client_max_body_size 1024m; }

try_files这行必须写上，否则前端路由用history模式时，用户刷新一个二级页面会直接404。这个问题我在上线当天才发现，用户反馈“列表页刷新就白屏”，其实就是少了这条配置。另外proxy_pass后有没有末尾斜杠，语义完全不同，写成http://127.0.0.1:8081和http://127.0.0.1:8081/传递的路径不一样，需要核对清楚，我建议直接在文档里锁死写法。

6.3 高频问题速查表

把开发到上线这段过程里碰到的高频问题整理成一个速查表，方便各位按图索骥：

维护这张表的过程其实也是给系统做体检的过程。我每次线上出问题，都会第一时间落到这张表里，后面团队同事再遇到相同问题时，查一下就能解决，不需要每次重新翻源码。

提示：生产环境的数据备份策略一定要提前想好。流量样本文件动辄上百GB，用全量备份成本太高，我这边采用的是“元数据每天全量备份到备份库 + 文件目录按周增量备份到冷存储”的策略，成本可控，恢复时也够用。

最后分享两个实操心得

这个系统做完之后，有个体会特别深：流量样本管理系统真正难的不是代码本身，而是对样本数据“规范”的坚持。如果你在录入第一条样本时就允许文件名乱起、标签乱写、分类字段随意填，那系统上线三个月后就会重新变成一个电子垃圾堆。我后来的习惯是，在系统里做了强制校验，比如源IP、目的IP格式不对不允许保存，标签字段建议用预置选项加自定义输入，分类必须选择。这些约束在最初会让人觉得繁琐，但数据量起来之后，你才会发现规范才是最大的效率来源。

另外一个建议是，文件存储目录的命名规则要跟样本表里的某个字段对应上，比如按“采集任务编号/日期”组织目录，这样哪怕数据库挂了，至少还能靠文件目录的命名找回一部分信息。我在设计目录时保留了“日期/任务名/文件名”的结构，从文件系统的视角也能大致看出样本来源。以后如果你们的数据量真的涨到单个服务器装不下，这套目录结构也能平滑切换到对象存储路径，代码改动量很小。

这套设计和实现方案，我后来又复用了两次，一次是做数据标注平台的前置样本管理模块，一次是做教学用的流量数据集管理后台，都是同一套Vue加Spring Boot的组合和同样的表结构思路。这说明只要把数据模型想清楚，技术框架反而是最不挑的那部分。如果你们也有这类样本管理的需求，先从元数据建模入手，把字段定细，把标签和分类想清楚，这个系统就已经成功七成了。