企业官网建设流程全解析

简介：来自2017年中国软件杯总决赛的二等奖项目完整归档，适合准备参加软件设计类竞赛的高校学生、团队及指导老师参考。压缩包共163个文件，约69.22MB，类型以Python源码（.py/.pyc）、Word设计文档（.docx）、可执行程序与依赖库（.exe/.dll）、Web前端页面（.html/.js/.css）为主，另有Visio流程图（.vsdx）、PPT、演示视频、报名表、项目使用说明、运行日志和Redis等中间件配置，覆盖从需求分析、系统设计、编码实现到部署展示的完整链路。通过设计文档可以了解作品的功能架构、模块划分和数据库设计思路；源码与编译产物便于对照研读核心业务逻辑；可执行程序与配置文件则展示了实际运行环境与中间件依赖。配套的PPT、演示视频和报名材料还呈现了现场答辩与作品包装的关键细节。目前已有63人学习下载，适合赛前方案对标、系统设计参考和二次开发学习，尤其对需要快速搭建竞赛项目骨架的开发者有直接借鉴价值。

1. 2017中国软件杯二等奖作品zip：不是解压就能跑，得先读懂这个包

你手里这个2017-中国软件杯-总决赛-参赛作品(二等奖).zip，大概率是从某个赛事资源站、网盘分享或往届学长手里拷贝下来的。文件名里已经给了三个关键信息：赛事年份（2017）、级别（总决赛）、获奖等级（二等奖）。但别急着双击解压——这类参赛作品包和普通源码 zip 最不一样的地方在于，它不是为了“克隆即运行”而打包的，而是为了“给评委看”而打包的。里面通常混着源码、演示视频、答辩 PPT、需求文档、数据库 SQL 脚本，甚至还有几份改了又改的说明文档。如果你直接照着源码跑，八成会卡在环境变量、绝对路径和依赖版本上。这篇文章就用我处理过十几个软件杯、挑战杯、服务外包赛包里摸出来的经验，带你把这个 zip 变成你能运行、能看懂、能拿来写简历的东西。新手能跟着走通，老手也能避开几个容易翻车的暗坑。目标只有一个：让这份二等奖真正变成你的动手能力，而不是躺在硬盘里的一个死包。

2. 解开zip前的三道安检：文件结构、压缩包类型与解压环境准备

2.1 先看压缩包的类型与完整性，别急着用“解压到当前文件夹”

拿到任何 zip，我习惯先做三件事：看扩展名、看体积、看是否能正常列出目录。很多网盘下载的参赛包其实是双重压缩，外层是 zip，里层又是一个 rar 或 7z；也有的包为了过附件大小限制，把大的演示视频单独拿掉，只留一个“资源缺失说明.txt”。如果你直接解压发现缺少/video或/database目录，先回头检查压缩包本身。

常见做法是用命令行验证，而不是依赖图形化工具。Windows 上我一般用tar（Win10 自带）或者 PowerShell 里的Expand-Archive，Linux/macOS 直接用unzip -l先列出文件清单。这样做有两个好处：一是能提前看到顶层目录结构，判断是不是套了一层没用的根文件夹；二是在不解压的情况下就能发现异常的压缩炸弹（比如某个文件占了几 GB，明显不像是参赛源码）。

# Linux/macOS 下先看清单，不实际解压 unzip -l 2017-中国软件杯-总决赛-参赛作品\(二等奖\).zip | head -50 # 如果系统没有 unzip，可以用 Python 的 zipfile 模块 python3 -c "import zipfile; z=zipfile.ZipFile('2017-中国软件杯-总决赛-参赛作品(二等奖).zip'); print('\n'.join(z.namelist()[:50]))"

这段命令的逻辑是：先把压缩包内部的路径、文件大小、压缩比例都列出来，头部 50 行足够让你判断这是“源码 + 文档”的结构，还是“一堆照片 + 一个 exe”的结构。参数说明：head -50只取前 50 行，避免刷屏；Python 方式则不受系统中是否安装 unzip 的限制，在 Windows 下同样能跑。注意文件名里的中文括号和空格，Shell 下必须用引号包住或加反斜杠转义，否则你会被unzip的“Cannot find zipfile”折磨半天。

2.2 识别包内结构与技术栈，判断这到底是个什么项目

列完清单后，你会看到一批目录名。软件杯参赛作品当年最常见的技术栈是 Java Web（SSH/SSM）、C# WinForm、Android App 和一部分早期微信小程序。怎么从文件名看出项目类型？看几个标志性文件：

• pom.xml、web.xml、WEB-INF是 Java Web（Maven 工程或传统 Web 工程）
• build.gradle、AndroidManifest.xml、src/main/java是 Android 项目
• *.sln、*.csproj、Form*.cs是 C# 项目
• app.json、pages/、project.config.json是微信小程序项目
• requirements.txt、manage.py、app.py是 Python Web
• package.json、server.js或webpack.config.js是 Node.js 项目

这一步决定了你后面用哪一套环境去跑。很多人翻车不是因为代码烂，而是因为“用一个 2021 年的 JDK 去跑 2017 年的 Java Web 项目”，然后被javax和jakarta的命名空间冲突按在地上摩擦。我一般会把pom.xml里的<java.version>或.classpath里引用的 JRE 版本先记下来，再去本机决定装哪个 JDK。对于 2017 年的比赛作品，Java 8 几乎是绝对主力，所以我的建议是：先装一个 Java 8 的 JDK，别用什么 11 或者 17 冒充兼容。微信小程序的原生框架也是同理，2017 年的开发工具版本对应的基础库很老，你现在用新版微信开发者工具打开，大概率会提示“基础库版本过低”，后面我们会专门说这个坑。

2.3 解压时的三个环境准备：路径、编码、工具链

解压动作本身也会埋坑。第一个坑是路径：绝对不要解压到C:\Program Files或者任何带空格的路径下，更不要解压到桌面的中文长路径里。2017 年的老项目经常硬编码绝对路径，比如D:\MyProject\WebRoot，你换台机器路径一变，配置文件直接失效。第二个坑是编码：很多当年上交的作品用的是 GBK 编码保存 Java 源码和 properties 文件，而现代 IDE 默认 UTF-8，解压后一打开就是乱码。我的习惯是在解压前先用unzip -O gbk（Linux 下）或 Bandizip 的“使用系统编码”选项，把文件名和内容一起转成 UTF-8。如果已经解压坏了，后面在 IDE 里可以强行改文件编码，但如果是数据库脚本被解压坏，那真要哭死。

第三个坑是工具链版本。2017 年的数据库脚本大概率是 MySQL 5.6/5.7 或 SQL Server 2008 的写法，你拿 MySQL 8.0 去跑，会遇到sql_mode严格模式导致的group by报错，或者utf8_general_ci和utf8mb4_0900_ai_ci的排序规则冲突。我的做法是：看 SQL 文件头部的注释，找到SET NAMES utf8或版本声明，然后在本地用一个独立 MySQL 5.7 实例（Docker 或直接装都行）去导入。有些作品还会带数据库连接配置文件db.properties，里面的 IP 是 10.0.1.5 这种校园内网地址，你在本机永远连不上。别改这个文件硬连，正确做法是导入脚本后，把连接串改成127.0.0.1:3306/数据库名。

准备好一个“最小运行环境清单”：JDK 8、MySQL 5.7、Python 3.6（如果项目是 Python 写的）、微信开发者客户端（老版本，如果你的 zip 里明确是微信小程序）。这份清单是我从一次次“解压、失败、再解压”里跳出来的标准配置，有了它，绝大多数作品都能在半天内跑起来。

3. 把二等奖作品从zip变成可运行工程：按项目类型分路启动

3.1 Java Web 项目：从解压到 Tomcat 跑通的最小命令集

当你在 zip 清单里看到pom.xml或.classpath时，这就是一个典型的 Java Web 项目。2017 年的软件杯作品，Java Web 组的题目多半是高校办事大厅、智能交通、大数据分析之类，技术栈用 Spring + Spring MVC + MyBatis（SSM）的占一大半。跑通它的路径是：解压、导入 IDE、修改数据库连接、选择 Tomcat、启动。

我的做法是不用 IDE 自带导入向导，而是先用命令行确认 Maven 能解析依赖。这样能早点暴露 JAR 包损坏、仓库源失效问题。

# 用 maven wrapper 或系统 mvn 先做依赖解析和编译 cd 项目根目录 # 通常是包含 pom.xml 的那一层 mvn clean compile -DskipTests -o false 2>&1 | tee build.log # 如果项目没有 mvnw，且系统 mvn 版本过高导致插件不兼容，就指定 maven 3.5 mvn -version

注意这里-DskipTests只跳过测试，不跳过编译；-o false是强制联网下载依赖的意思（写成-U更常见，强制检查远程更新）。tee build.log能把编译输出同时打到屏幕和文件，方便事后翻日志。跑完看 BUILD SUCCESS 还是 FAILURE。如果报错是找不到ojdbc或某个 Oracle 驱动，说明项目用了 Oracle 数据库而你自己没有对应 jar，常见做法是去官网下载驱动或者换成 MySQL 版本。如果是 Maven 私有仓库地址失效（2017 年的仓库地址很多现在已经 404），需要把~/.m2/settings.xml里的镜像改成阿里云或腾讯云。

编译通过后，配置 Tomcat。常见做法是把项目打成 war 包，丢到 Tomcat 的webapps下，或者直接在 IDEA/Eclipse 里配置 Tomcat Server。我本人更偏向命令行方式：先mvn package产出 war，再复制到 Tomcat 的 webapps 目录，启动 Tomcat，看日志。

# 打包 war，跳过测试 mvn package -DskipTests # 把 war 复制到 tomcat 的 webapps 下 cp target/*.war ${TOMCAT_HOME}/webapps/ROOT.war # 启动 tomcat（catalina.sh 在 bin 目录下） ${TOMCAT_HOME}/bin/catalina.sh run

catalina.sh run是把 Tomcat 在前台运行，日志直接刷在控制台，方便你看到Deploying web application archive以及/WEB-INF/classes里的启动错误。如果端口被占用，改conf/server.xml里的 Connector 端口。跑通访问http://localhost:8080/index.jsp或项目上下文路径。这里有一个容易忽略的点：很多奖项作品的首页不是 index.jsp，而是一个 redirect 到登录 servlet 的地址，所以你看到 404 别慌，先去web.xml里查<welcome-file>配置。

3.2 微信小程序项目：用开发者工具打开前的三个参数修正

2017 年恰好是微信小程序兴起的一年，软件杯有赛道专门收小程序作品。这类 zip 通常包含app.js、app.json、pages/目录，以及一个或多个project.config.json。解压后你直接用新版微信开发者工具导入，十有八九会发现代码提示一堆 API 不存在，比如wx.openLocation或者wx.getLocation的老样式。原因很简单：小程序基础库版本一直在涨，2017 年的代码用的是老 API 签名，新的基础库还保留但报 deprecation。

我的做法是先用文本编辑器打开project.config.json，把其中的"libVersion"字段改成一个比较低而且稳定的版本，比如"1.5.0"或写作"miniprogramRoot"里面指定的根目录。同时要检查project.config.json里是否设置了"urlCheck": true，这个开关是域名校验，2017 年的项目后端地址经常是 IP 或 localhost，不关掉的话请求一律被拦截。

{ "miniprogramRoot": "miniprogram/", "appid": "touristappid", "setting": { "urlCheck": false, "es6": false }, "compileType": "miniprogram", "libVersion": "1.5.0" }

这段配置里有两个关键点：appid置为"touristappid"表示游客模式，不需要注册小程序账号就能编译预览；es6: false是因为部分 2017 年老代码用了 ES5 写法，打开 ES6 转译反而会出奇怪的语法错误。libVersion我建议先看看项目里有没有调用getUserInfo这种已被废弃的接口，有的话用 1.5.0 或 1.9.0 比较稳妥。设置完成后，用新版微信开发者工具导入项目根目录，编译预览就能看到页面。

另一个坑是开发者工具本身。如果你现在手头只有最新版工具，它会强制要求基础库版本大于等于某个值，导致你在模拟器里看到一堆兼容性小黄条。我的通用解决方法是：在工具内“详情 - 本地设置”中勾选“不校验合法域名、web-view、TLS 版本以及 HTTPS 证书”，并且把调试基础库版本在“详情 - 调试设置”里手动选为 1.5.0。如果新版工具已经移除了旧版本选择，那就必须去官网装一个 2018 年左右的开发者工具版本，这个不用有心理负担，老工具配老项目，属于常规操作。

3.3 数据库脚本导入：老版本 MySQL 的兼容性救法

参赛作品一般会附*.sql文件，文件名常是db_softwar_cup.sql或者init.sql。直接双击用 Navicat 导入不是不行，但报错概率高，尤其是遇到 MySQL 8.0 的 sql_mode 严格模式。

-- 先看脚本头部注释，判断目标版本 SET NAMES utf8; SET FOREIGN_KEY_CHECKS = 0; -- 这条语句是 2017 年作品的常见写法，如果报错，说明是新版本 MySQL 不兼容 CREATE TABLE IF NOT EXISTS `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(20) DEFAULT NULL, `password` varchar(50) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户信息表';

这段 SQL 本身没毛病，但在 MySQL 8.0 里会因为int(11)显示宽度和utf8字符集引起 warning 甚至 error。更常见的是脚本里用了过时的TYPE=InnoDB或者DEFAULT CHARSET=utf8，这些不会致命，最致命的是group by后面的非聚合列配合only_full_group_by模式直接报错。我的一般处理流程是：先用编辑器打开 SQL 文件，全局搜索sql_mode，如果没搜到，就手动加一句SET sql_mode = '';放到文件最上面，再用命令行导入。

# 在 MySQL 5.7/8.0 下以宽松模式导入脚本 mysql -u root -p --default-character-set=utf8 -e "SET GLOBAL sql_mode='';" mysql -u root -p --default-character-set=utf8 mydb < init.sql

这条命令先把服务器全局sql_mode清空，再导入数据。注意mysql客户端和mysqld服务的字符集要一致，--default-character-set=utf8是必须的，否则脚本里的中文注释和表注释会变成乱码。如果脚本里有外键和存储过程，建议先导入结构，再导入数据，分开执行，否则前一步失败后面全都白跑。

4. 参赛作品里的高分密码：评审视角下的技术点拆解

4.1 二等奖作品的文件组织套路：源码、文档、演示三者缺一不可

软件杯总决赛二等奖的评审标准不只是“功能跑通”，更看重完整度。从大量这类 zip 的文件清单来看，高分的包都有一个共性：存在Document/、演示视频/、答辩PPT/和源码/四个独立目录。这既是给评委看的，也方便我们后来者理解项目脉络。

我看一个作品是否值得学习，第一件事是打开它的需求文档.pdf或设计说明书.docx，看里面的“系统总体架构图”和“模块划分”。2017 年很多二等奖作品都会画一张用 Visio 或 PowerPoint 画出的三层架构图，把表示层、业务层、数据层标得很细。真正值钱的不是那张图，而是图中每个模块之间的箭头有没有和代码里的包名对应起来。常见做法是源码的src/main/java下面按controller/service/dao分包，如果 doc 里的包名和源码包名能对得上，说明不是网上抄的框架拼凑品，而是真做过设计。反之，如果 doc 上说“采用 SSH 框架”，代码里却连hibernate依赖都没有，那就是典型的文档与代码脱节，这种作品学习价值有限。

其次看SQL脚本里的数据字典。二等奖作品经常会建几十张表，表前缀可能是t_、sys_、biz_，设计上分了业务表、系统表、日志表。我一般会挑核心业务表（比如订单表、用户表）看字段注释，注解得详细说明作者对业务的理解程度。很多获奖作品会在核心表上做冗余字段，比如在order表里直接存username，而不是只存user_id，这种设计在 2017 年的课程作业里很常见，但真实企业里是反模式。看的时候要有批判性，别把二等奖当教科书。

4.2 从代码风格看评审加分项：命名规范、注释密度和防御性写法

二等奖和一等奖的差距往往就在代码细节上。一等奖的代码读起来像正规公司的，二等奖的代码读起来像竞赛项目组加班赶的。但即便如此，二等奖的代码里也有不少值得摘抄的习惯。比如包名全小写、类名大驼峰、方法名小驼峰，变量名像resultList而不是list1。再看异常处理：获奖作品通常会在 service 层抛出自定义业务异常BusinessException，而不是在 controller 里裸 catchException。这个习惯可以直接学。

注释方面，我见过若干个二等奖作品，类头部注释写着作者、日期、版本，方法上写@param和@return。虽然这种注释经常是 IDE 自动生成的，但至少表明团队有意识做规范。真正加分的注释是写在复杂业务逻辑里的中文说明，比如“如果订单状态为待支付并且超时30分钟，则自动设置为关闭”。这种注释说明作者不光为了跑通，还想让后面的人能接手。

防御性写法上，获奖作品一般在 controller 里做参数校验，比如判断空字符串、长度限制，而不只是依赖前端。代码里会有大量if (xxx == null || xxx.isEmpty()) { return Result.fail("xxx不能为空"); }。你可以把这些校验抽成统一的方法，下次做工程时直接用这个模式。还有一种低级但普遍的坏味道，是密码明文存数据库、System.out.println直接打日志。看到这些，你的反应不应该是“二等奖不过如此”，而是“我能做得比它好”，这才是你复读这份 zip 的最大收获。

4.3 演示视频与答辩 PPT：被学历歧视最多的“技术资产”

很多人拿到 zip 后只盯源码，忽略了演示视频.mp4和答辩PPT.pptx。这两个文件才是二等奖作品能获奖的临门一脚。评审现场一分钟可能看不了几十个页面，一段 5 分钟操作演示视频加上 15 页的 PPT，足以把你的系统讲清楚。对后来者，这份材料是绝佳的“需求说明书+用户手册”二合一资料。

我一般会重点看 PPT 里的“系统创新点”页，以及“同类产品对比”页。2017 年的比赛题目通常来自企业实际需求，比如“智慧校园导览”“智能垃圾分类”“考勤系统”，这些题目的创新点往往集中在算法调用、数据可视化、硬件对接。而二等奖的创新点一般不是原创算法，而是“将某开源库集成到系统里并做出了可用产品”。例如在libs/目录下你会发现fastjson.jar、poi.jar、jfreechart.jar，甚至人脸识别的离线 SDK。这意味着选手清楚“能用现成的就别自己造”这条工程铁律，这也是值得所有读包的人记住的高分密码。

5. 解压运行参赛作品时的常见问题：5个避坑记录

5.1 乱码横飞：GBK和UTF-8互相伤害

现象：Java 源码在 IDEA 里打开全是��，数据库脚本导入后中文注释变问号，浏览器页面显示 response 中文乱码。

原因：2017 年 Windows Eclipse 默认用 GBK 编码保存.java和.properties，而我从 Linux/macOS 角度解压时默认 UTF-8。IDE 读取时用 UTF-8 解码 GBK 内容，自然乱码。

解决：解压前用unzip -O gbk强制把文件名解析为 GBK；解压后用 IDE 的文件编码设置逐个改成 GBK。小技巧是先用 Notepad++ 或 VS Code 打开任意一个源码文件，用“重新打开 with encoding”找到 GBK 选项，如果不再乱码，就说明文件本身的编码确实是 GBK，然后批量转换。数据库脚本同理，打开前先看头两行注释，如果是-- 功能说明这类中文且文件底部没有UTF-8标记，就按 GBK 导入。命令行加--default-character-set=gbk导入成功后，再导出为 UTF-8 版本。

5.2 MySQL 版本导致 SQL 导入失败

现象：导入init.sql时出现ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause ...或者Unknown collation: 'utf8mb4_0900_ai_ci'。

原因：MySQL 8.0 默认sql_mode中包含ONLY_FULL_GROUP_BY，且默认排序规则是utf8mb4_0900_ai_ci，老脚本里写的是utf8_general_ci。建表语句里的ENGINE=InnoDB DEFAULT CHARSET=utf8不会触发排序规则错误，但插入数据的 SQL 可能用了utf8_unicode_ci戳。

解决：最省事的方法是装一个 MySQL 5.7 的 Docker 容器，专门用来跑老项目：

docker run --name mysql57 -e MYSQL_ROOT_PASSWORD=root -d -p 3307:3306 mysql:5.7 mysql -h 127.0.0.1 -P 3307 -u root -p < init.sql

这里把容器端口映射到宿主机 3307，避免和 3306 上的新版本冲突。如果不想用 Docker，就按第 3 节的方法清除全局sql_mode。注意如果脚本里创建数据库时带了CHARACTER SET utf8 COLLATE utf8_general_ci，那也要和导入客户端字符集匹配，否则表名和字段名可能走默认集导致索引长度超限制。

5.3 Tomcat 8080端口被占用并且启动失败

现象：双击catalina.sh run后，日志出现SEVERE: StandardServer.await: create[8080]或者Port 8080 required by Tomcat v9.0 Server ... is already in use。

原因：本机有别的服务占用 8080，比如开发后端、数据库 Web 控制台、或者你自己之前起的另一个 Tomcat。老项目对端口没有感知，配置文件里写死了 8080。

解决：不要用杀死进程的方式，直接改 Tomcat 的conf/server.xml里的<Connector port="8080" protocol="HTTP/1.1" ... />改成 8081。但要注意，项目源码里的baseUrl、web.xml里的回调地址也可能写死了 8080，需要全局搜索替换。另外，如果 Tomcat 因为缺一个JAVA_HOME环境变量而闪退，记得先 echo 检查 JDK 8 路径对不对。

5.4 微信公众号服务号回调地址被新接口规则拦截

现象：将含微信小程序的作品跑起来后，点击“登录”按钮没有任何响应，控制台报net::ERR_NAME_NOT_RESOLVED或者后台服务无法收到微信服务器回调。

原因：2017 年的小程序项目普遍使用wx.request调用后端 HTTP IP 地址，而现在微信要求业务域名备案，IP 直连在真机预览会被拦截。在开发者工具本地则是因为urlCheck默认 true。

解决：在开发者工具详情页勾选“不校验合法域名、web-view、TLS 版本以及 HTTPS 证书”，并把project.config.json的urlCheck改成 false。如果项目里用到了 web-view 跳转网页，也要把页面域名加入业务域名或者改为本地调试模式。另外要注意 2017 年的wx.login接口返回 code 的时效性现在更短了，可能 5 分钟就过期，调通后要快速测试。

5.5 源码包中引用的本地jar包全部失效

现象：导入 IDE 后，lib/或者WebContent/WEB-INF/lib下的所有 jar 包显示红色感叹号，Maven 仓库里也找不到，项目无法编译。

原因：很多 2017 年作品为了省事，直接把需要的 jar 包放在源码工程目录下，这些 jar 是当时的第三方包版本，比如ojdbc14.jar、commons-httpclient-3.1.jar、json-lib-2.4.jar。如果涉及商业 Oracle 驱动，官方已经不公开下载；如果是岁月原因从网盘拷肉，压缩包里这些二进制文件可能损坏。

解决：先刷新mvn dependency:sources看能不能从公共仓库拉替代版本。对于 ojdbc 这种，建议换成 MIT 协议的 MariaDB Connector/J 或 MySQL Connector/J 来兼容，但前提是项目里的 SQL 没有强依赖 Oracle 特性。如果是commons-httpclient，可以用 Apache HttpClient 4.x 兼容，但接口改动大，需要改代码。这个坑我通常绕开：先看这些缺失 jar 是不是核心逻辑依赖，如果只是次要工具包，就在 IDE 里手动加入同样功能的现代 jar 进去并修复 import 路径。如果动不动就缺 20 个 jar，果断放弃本机编译，改用 Docker 镜像跑一个 2017 年的 Java 8 + Tomcat 8 环境，把工程放进去调试。

6. 把整个项目重新打包成zip：复盘与复用的交付技巧

等这台跑通后，别急着把目录关掉。这时候最该做的一件事，是在你自己电脑上重新打包一份干净的可交付 zip。这不是为了发朋友圈，而是为了让你在答辩、写简历、交接给别人的时候，能少踩一轮自己刚才踩过的所有坑。我的习惯是先清理掉工程里的临时文件，再压缩。

# 在项目根目录上一级执行，排除 IDE 配置、编译产物和数据库本地文件 zip -r ../复试项目复现-2017软服杯.zip . \ -x "*.idea/*" -x "*.iml" -x "target/*" \ -x "*.class" -x "*.log" -x "*.DS_Store" \ -x "*.war/*" -x "db/本地备份/*"

这条命令把整个目录压缩时删掉不需要的垃圾文件。参数-x后面跟排除规则，*.class和target是 Maven 编译产物，.idea是 IntelliJ IDEA 的本地配置，这些对别人无用且容易造成路径冲突。注意我故意没有排除lib/下的第三方 jar，因为这是别人拿来直接运行的基础。

如果你压缩时希望保留 Unix 文件权限（比如 shell 脚本），加-X排除额外属性，或者反过来用-y保存符号链接。但我这边实际操作时，最关心的还是中文文件名和权限问题，所以我会用zip -r时先执行zipinfo -1 文件名 | grep -P检查是否有不可见字符。否则上传到某些在线评测环境时，中文文件名会变成???。

打包完成后，还需要在压缩包内附上一份README-环境说明.md，写上 JDK 版本、MySQL 版本、Tomcat 路径、数据库连接账号密码、以及你自己复现时的修改点（比如改过sql_mode和project.config.json）。这份文档的价值，是让你三个月后回过头来看还能想起当时怎么跑通的。我见过太多人花两周复现别人的作品，却没有花十分钟记录自己怎么踩坑的，等到要再打开时，又是新的一轮翻车。

最后一个技巧是：在README里加上一行“复现负责人：xxx”和“复现日期”，并把你修改过的核心配置用diff命令导出一个 patch 文件放进原项目里：

# 假设你保留了一份原始解压目录 original，修改过的目录 fixed diff -ruN original fixed > 复现改动.patch

这个patch文件就是这个 zip 对你而言最有价值的产出，它记录了从“二等奖作品”到“能跑的二等奖作品”之间所有的血泪经验。下一次遇到类似的参赛包，直接套用这些经验，就能省下至少两个小时的无效试错。这也是我把这个 zip 从一堆代码变成自己能力的方式。希望帮到你。

本文还有配套的精品资源，点击获取