区块链工程专业毕设选题这件事，每年九月到十一月都是讨论最集中的时候。我前后帮几届学生看过开题报告，也参与过一些校内的中期检查和答辩旁听，见过太多人一开始选题选偏，后面三个月全在填坑。这篇内容面向的是 2026 届区块链工程及相关方向的本科生，也适合带毕设的青年教师和刚入门的同学参考。我会把选题的逻辑、可落地的方向、技术栈怎么选、工作量怎么估、开题到答辩这条链路上容易翻车的地方，全部摊开讲一遍。核心关键词就一个：区块链工程专业毕设选题。读完之后，你至少应该能判断出哪些题目是"看着唬人但做不出来"，哪些题目是"名字朴素但能拿高分"。
1. 先搞清楚：毕设选题到底在选什么
1.1 选题不是选技术，是选一个能被验证的问题
很多人把毕设选题理解成"我要用哪个链、学哪个框架"，这个顺序是反的。评审老师看一份开题报告，第一眼找的是"你要解决什么问题"，第二眼才是"你用什么技术解决"。区块链这个方向尤其容易跑偏，因为技术名词密度太高，学生容易把技术堆砌当成创新点，写出来的开题是"基于 Fabric 的联盟链系统设计与实现"，问题是这个描述可以套在任何一个系统上，没有指向性。
我的建议是把选题拆成三层：问题层（谁在什么场景下遇到了什么麻烦）、机制层（区块链的哪个特性——不可篡改、多方共信、可追溯、合约自动执行——正好能缓解这个麻烦）、交付层（最后交出一个什么形态的东西：可运行系统、检测工具、仿真实验、对比分析报告）。三层都要写清楚，缺一层就会在答辩时被追问。
举个反面例子，某同学开题写"基于区块链的投票系统"，问题层几乎是空的——为什么要用链？中心化数据库哪里不够？如果答不上来，这个题目就只是把增删改查换了个存储后端。反过来，如果你说的是"多院系联合活动中的评选结果需要各方都不完全信任彼此，需要一套任何一方都无法单方面修改的记票与审计机制"，问题层就立住了，后面的技术选型也顺理成章。
1.2 2026 届的现实情况：技术栈和评审口味都在变
这两年我观察到的变化有三个，值得在选题时考虑进去。
第一，纯合约开发的题目性价比在下降。写一个 ERC 标准的合约、部署到测试网络、做个前端页面调一调，这套流程现在网上教程太多，评审一看就知道是照着做的，创新点很难说清楚。除非你在合约逻辑本身有东西——比如设计了一套新的多方结算规则，或者做了系统的安全分析——否则不建议只做这一层。
第二，联盟链方向依然是本科毕设的舒适区。Fabric 和 FISCO BCOS 这类开源联盟链框架，文档齐全、社区活跃、部署相对可控，而且在存证、溯源、多方协作这类场景里故事讲得通。本科生做联盟链，工作量可以自己控制：想多做就加隐私保护、加跨链、加压测；想稳一点就把业务流程做扎实。这是我认为最不容易翻车的选择。
第三，安全和隐私成了加分项而不是可选项。现在的答辩现场，"你这个系统的数据上链了，那隐私怎么办"几乎是必问题。如果你在开题阶段就把隐私方案（哪怕是通道隔离、私有数据集合这种相对简单的做法）写进去，会显得你想得比别人远一步。
1.3 三类题目的难度与风险对照
我把常见的题目分成三类，你可以先对号入座。
| 类型 | 典型形态 | 工作量可控性 | 主要风险 | 适合谁 |
|---|---|---|---|---|
| 应用系统型 | 存证、溯源、身份管理、学分互认 | 高，可裁剪 | 业务流做太薄，被认为"只是套壳" | 大部分同学，尤其时间紧的 |
| 工具/分析型 | 合约漏洞检测、性能压测、交易行为分析 | 中，依赖数据集 | 数据集拿不到，结论站不住 | 有一定编程基础、喜欢做实验的 |
| 算法/机制型 | 共识算法改进、激励机制设计、隐私方案对比 | 低，容易被数学卡住 | 仿真结果不理想，无法自证 | 数学基础好、打算读研的 |
表格里"工作量可控性"这一列是我最看重的。本科毕设的周期通常 16 周左右，中间还有秋招、考研、实习，真正能沉下心写代码的时间可能只有两个月。选一个能随时裁剪功能的题目，比选一个"理想很丰满"的题目要明智得多。算法型题目不是不能选，但一定要提前想好退路：如果仿真结果和预期不一致，你的论文还能不能写下去？能写成"对比分析"而不是"改进有效"，就算有退路。
2. 六个可落地的选题方向拆解
2.1 方向一：多方存证与审计（最稳的保底方案）
这是我认为最不容易出问题的一类。核心逻辑很简单：多个参与方需要对同一批文件、记录或操作留痕，任何一方都不应该能偷偷改动历史，出了问题要能追溯。
问题场景可以设计成：某高校的几个部门之间需要共享一批材料（比如设备借用记录、实验室安全检查记录、成果登记），传统做法是各自存一份 Excel，对不上账的时候互相扯皮。用联盟链把关键字段的哈希上链，原始文件仍然放在各自服务器或对象存储里，链上只留指纹和操作记录。
技术实现上用 Fabric 或 FISCO BCOS 都行。Fabric 的话，两个组织、一个通道、一个链码，链码里存{文件ID, 哈希, 提交方, 时间戳, 前序哈希}，查询用 CouchDB 的富查询做条件筛选。FISCO BCOS 的话，用 Solidity 写合约，Java SDK 或 Python SDK 对接，配一个 WeBASE 做可视化管理界面，演示效果会好很多。
核心工作量在于：链码/合约设计、SDK 封装、批量上链的性能处理、审计查询接口。想加分的话，把"批量上链"做成异步队列，测一下不同批量大小下的 TPS 和延迟，这就是一组能写进论文的实验数据。
坑点：不要把文件本身放到链上。我见过有同学把几百 KB 的图片直接存进链上状态数据库，跑两天数据库就爆了。链上只存哈希，这是铁律。另外哈希算法要写清楚用的是什么（SHA-256 还是国密 SM3），如果学校有国密要求，FISCO BCOS 是支持国密算法的，这一点可以提前确认。
2.2 方向二：供应链/流转溯源（故事最好讲，但要做深）
溯源是区块链最经典的叙事，也是最容易被做成"扫码看网页"的题目。要拿高分，关键在于把"链上数据和链下实物如何锚定"这个问题正面回答掉。
我的建议是设定一个相对封闭、环节不多的场景，比如某类实验耗材从采购到领用到报废的全流程，或者某批设备在校内多个实验室之间的流转。环节少，你才能把每一步的参与方、数据结构、上链时机写清楚。
做深的具体办法有三个：
一是设计分层数据模型。链上存关键事件（谁在什么时间对哪个对象做了什么操作），链下存详细信息和附件，两者用哈希关联。论文里可以画一张数据分层图，说明哪些字段必须上链、哪些可以不上链、判断依据是什么。
二是处理异常流程。真实业务里一定有退货、撤回、数据录错的情况。传统溯源 Demo 只做正常流程，你如果把"错误上链后如何更正"设计出来——比如用一条冲正记录覆盖，而不是直接改数据——这就是很实在的加分点。
三是做一次可信性分析。列出系统里所有可能的作弊路径（参与方伪造扫码、链下数据与链上哈希不一致、合谋修改），逐条说明你的方案能防住哪些、防不住哪些。这种诚实的分析在答辩时非常加分，老师问什么你都答得上。
技术栈：FISCO BCOS + Solidity 合约 + Spring Boot 或 Flask 后端 + 小程序或 Web 前端。二维码用开源库生成即可。
2.3 方向三：智能合约安全检测与分析（偏研究，适合想读研的）
这个方向不要求你从零造一个检测工具，合理的做法是在现有工具基础上做组合与评测。比如把 Slither、Mythril 这类开源静态/动态分析工具跑在一个自己整理的合约样本集上，比较它们的检出率、误报率、耗时，然后针对某一类漏洞（重入、权限缺失、随机数可预测、时间戳依赖）提出一个轻量的检查规则或用例模板。
关键在样本集。你可以从开源合约库里爬取，也可以自己写一批带有已知缺陷的合约。后者更可控，而且论文里可以附上完整源码，可复现性强。写样本的时候注意覆盖不同复杂度的合约：单文件的小合约、带继承的合约、带外部调用的合约。
实验设计要提前想好：检出率怎么算？误报怎么人工判定？耗时在什么环境下测的？这三个问题答不上来，论文的实验章节就空了。
坑点：这类题目最大的风险是"做完了发现结论是'三个工具各有优劣'"。这个结论没有价值。你要在设计之初就锁定一个具体问题，比如"针对某类漏洞，现有工具在带继承结构的合约上漏报明显"，然后去验证它、解释它、给改进。有了明确假设，即使结论是否定的，论文也成立。
2.4 方向四：链上链下数据协同与隐私保护（难度中上，含金量高）
区块链的公开可验证性和数据隐私天然冲突，这个矛盾本身就是很好的毕设命题。本科层面不必碰零知识证明的底层实现，但可以做方案对比与工程落地。
具体可以这样设计：一个多方共享的业务系统，部分字段需要对特定参与方可见。你用 Fabric 的通道隔离做一版，用私有数据集合（Private Data Collection）做一版，再对比两者的隔离粒度、性能开销、运维复杂度。这个对比实验做扎实了，就是一篇结构完整的论文。
如果学校有可信执行环境方面的资源，也可以做一层 TEE 方案的原型，但这个对硬件有要求，没有条件就不要硬上。同态加密方向我不建议本科生碰，数学门槛和工程复杂度都偏高，容易陷进去出不来。
加分点：把"哈希上链 + 盐值 + 按需披露"这套轻量方案讲清楚。它的思路是链上只存加盐哈希，持有原始数据和盐值的一方能向验证方证明数据一致性，其他人拿到哈希也还原不出内容。实现简单，但概念是对的，答辩时能自圆其说。
2.5 方向五：数字身份与权限管理（贴近标准，容易写出规范感）
围绕分布式身份标识（DID）和可验证凭证（VC）做一套原型，是这两年比较新的方向。你可以设计一个"校内技能证书/培训记录"的签发与验证流程：签发方签发凭证，持有方保存，验证方在不联系签发方的情况下验证凭证有效性。
技术实现上，可以用以太坊本地测试链（Hardhat 或 Foundry 起一条本地链）部署注册合约和凭证状态合约，也可以用联盟链。凭证本身用 JSON 结构存链下，链上只存标识和状态（有效/撤销）。
这个方向的优势是有国际标准和规范文档可以参考，写出来的开题报告和论文结构会显得很正式，术语使用也规范。劣势是容易写成"概念介绍 + 简单 Demo"，如果你只做了签发和验证两个接口，工作量会被质疑。
补救办法是做完整生命周期：签发、持有、出示、验证、撤销、过期处理，每个环节都要有对应的合约方法和测试用例。撤销机制尤其要想清楚，链上撤销列表怎么做、隐私怎么保护、验证方怎么高效查。这块展开讲，内容就够了。
2.6 方向六：共识与性能仿真（想读研、数学不差的可以考虑）
如果你打算继续读研，做一个共识算法或性能优化的仿真实验是合适的。但必须把预期放现实：本科阶段的目标不是提出一个全新的共识算法，而是在已有算法上做参数敏感性分析或场景适配。
可行的做法：选 Raft 和 PBFT 两类共识，在一个模拟网络环境里做对比，变量包括节点数、网络延迟、丢包率、恶意节点比例（对 PBFT 类），指标包括吞吐、确认延迟、通信开销。用 Python 或 Go 写一个简化的事件驱动仿真器，几千行代码就能跑起来。
要注意的是：仿真器必须写清楚简化了哪些东西，为什么可以简化。答辩老师如果问"你的仿真和真实网络差多少"，你要能回答。另外结论不要夸大，说"在 XX 条件下 A 比 B 吞吐高 XX%"就可以了，别说"A 全面优于 B"。
这个方向我唯一的忠告是：先跑通再优化。很多人一上来就设计复杂的攻击模型，结果仿真器本身有 bug，跑出来的数据自己都不敢信。
3. 技术栈选型与工作量估算
3.1 底层链怎么选：三个方案的实话实说
| 方案 | 上手难度 | 文档与社区 | 演示效果 | 适合的题目 |
|---|---|---|---|---|
| Hyperledger Fabric 2.x | 中高，概念多（通道、组织、背书策略） | 官方文档完善，中文资料多 | 中，需要自己做管理界面 | 存证、溯源、多方协作、隐私对比 |
| FISCO BCOS | 中，国内文档友好，工具链完整 | 中文文档质量高，有配套中间件 | 好，WeBASE 有现成界面 | 存证、溯源、教学演示类 |
| 以太坊本地测试链（Hardhat/Foundry） | 低，合约开发体验最好 | 资料极其丰富 | 好，区块浏览器直观 | 合约安全、DID、凭证、小额结算类 |
我的实际建议是：如果你之前没接触过联盟链，选 FISCO BCOS，它的部署脚本和一键搭链工具能省掉大量环境折腾时间；如果你的重点是合约逻辑本身，用以太坊本地测试链 + Hardhat，开发调试效率最高；如果导师明确要求用 Fabric 或者实验室已有 Fabric 环境，那就跟着环境走，别自己另起一套。
无论选哪个，有一个原则：不要同时用两套链。我见过有同学想"联盟链做业务、公链做存证"，结果两套环境都要调，最后哪套都没做透。跨链是研究生课题，本科阶段碰它属于给自己加难度。
3.2 链交互层与前端：能省则省，但别省错地方
后端 SDK 封装是必须自己写的，这部分的代码量和技术含量都要体现在论文里。以 FISCO BCOS 为例，Java SDK 要封装连接管理、合约调用、事件监听、异常重试这几个模块，每个模块的职责要分开，别写成一个大类几百行。
前端我建议用最熟悉的技术，Vue 或 React 都行，甚至纯 HTML + 少量 JS 也能接受。评审看的是系统能不能跑通、逻辑对不对，不是前端好不好看。但有一个地方不能省：交易上链后的状态反馈。点击"提交"之后，界面要能显示交易哈希、区块高度、确认状态，这个细节最能体现你对区块链"异步确认"这件事的理解。
3.3 十六周工作量拆解
这份表是我按常见节奏排的，你可以根据自己情况调整，但比例大致是可靠的。
| 阶段 | 周次 | 主要任务 | 交付物 |
|---|---|---|---|
| 调研与选题 | 1-3 | 读 15-20 篇文献，确定场景和技术栈，写开题 | 开题报告 |
| 环境搭建 | 4-5 | 搭链、跑通官方示例、写第一个合约/链码 | 可运行的最小环境 |
| 核心功能开发 | 6-10 | 合约设计、SDK 封装、业务接口、前端联调 | 可演示的系统 |
| 测试与实验 | 11-13 | 功能测试、性能压测、对比实验、数据整理 | 实验数据与图表 |
| 论文撰写 | 14-15 | 按章节写，边写边补图 | 论文初稿 |
| 修改与答辩 | 16 | 根据导师意见修改，准备演示和问答 | 终稿与答辩材料 |
要特别提醒的是第 4-5 周。环境搭建是整条链路上最容易卡住的地方，我见过有同学在这一步耗了三周，直接压缩了后面的开发时间。对策是：提前准备好离线依赖包和镜像，把官方 Quick Start 完整跑一遍再动手改；遇到问题先在社区搜，别自己硬啃。
3.4 硬件与环境的最低要求
本地开发建议 16G 内存起步，Fabric 多节点跑起来对内存消耗不小。硬盘留出 50G 以上，Docker 镜像和链数据都比较占空间。如果笔记本配置吃紧，可以考虑把链部署在实验室内网的一台机器上，本地只跑客户端代码。
系统层面，Linux 或者 WSL2 的体验明显好于纯 Windows 环境，很多脚本默认就是 bash 的。版本管理用 Git，这一点没什么好商量的，代码丢了哭都来不及。
4. 从开题到答辩的实操过程
4.1 开题报告怎么写才不会被毙
开题报告被打回，八成是这三个原因：题目太大、创新点说不清、进度安排不现实。
题目太大最典型的表现是"基于区块链的 XX 系统"，XX 是一个巨大的领域，比如"教育""医疗""物流"。改法是把范围收窄到具体场景和具体参与方，比如"面向多实验室设备共享的流转记录存证系统"。
创新点这一栏，本科生不要硬凹"算法创新"。我认为更诚实的写法是从这三个角度找：场景适配（把通用方案落到一个具体业务的约束条件下）、方案组合（把两种已有机制组合解决一个新问题）、实验补充（对已有方案做系统评测，给出选型建议）。这三类都是站得住的贡献。
进度安排要留缓冲。别把每周都排满，至少要留出两周的机动时间。评审老师看到紧凑到没有余量的计划，第一反应是"这学生没做过项目"。
4.2 核心功能实现顺序：先闭环比先完美重要
我强烈建议在第六周之前做出一个最小可运行闭环：一个参与方能提交一条记录，链上能查到，另一个参与方能验证，整个流程能走通。哪怕界面很丑、只支持一个字段、没有异常处理，都没关系，闭环本身就是最大的心理保障。
有了闭环，后面所有工作都是在这个骨架上加东西：加参与方、加字段、加校验、加异常流程、加性能优化。没有闭环，你写了三千行代码也不知道能不能跑起来，这种焦虑会严重影响后面的进度。
具体的实现顺序我推荐这样：合约/链码 → SDK 调用 → 后端接口 → 前端页面 → 联调 → 加异常分支。每一步都要能单独测通再进下一步，别一口气写完再一起调，出了问题根本定位不到。
4.3 性能实验怎么做才不算凑数
很多论文的性能章节就是一张"TPS 达到 XXX"的表，没有任何解释，这是无效数据。有用的性能实验必须交代清楚：测试环境（机器配置、节点数、网络条件）、测试方法（并发数怎么加、持续多久、预热了没有）、指标定义（TPS 是成功交易还是提交交易？延迟测的是哪个环节？）。
举个具体的做法：固定区块配置，把并发从 50 逐步加到 500，每个档位跑 3 分钟，记录成功率和平均延迟，画出拐点。你会看到某个并发之后成功率断崖式下跌，这个拐点就是系统的实际承载上限，比单说一个 TPS 数字有说服力得多。
如果做的是方案对比（比如通道隔离 vs 私有数据集合），那就固定业务负载，只改隔离机制，其他变量全部锁定，测出来的差异才能归因到隔离机制上。控制变量这件事，写在论文里就是严谨性的体现。
4.4 论文结构和代码怎么对应
论文不是代码说明书，但也不能和代码脱节。我建议的对应关系是：需求分析对应场景调研和参与方梳理；系统设计对应架构图、数据模型、合约接口定义；实现章节对应关键模块的核心代码片段和设计决策说明；测试章节对应实验设计和数据。
有个小技巧：写代码的时候就随手记"设计决策日志"，比如"为什么这里用哈希索引而不是直接存原文""为什么这个校验放在链上而不是链下"。这些一两句话的记录，写论文时会变成最有价值的段落，答辩被追问时也是现成的答案。
5. 常见问题与排查实录
5.1 环境类问题的排查思路
链起不来，九成是这三类原因：端口冲突、证书/配置不一致、依赖版本不匹配。排查顺序我一般是：先看日志报错的关键词，再确认容器状态，最后核对配置文件里的 IP、端口、路径是否和实际环境一致。
Fabric 的证书问题尤其磨人，组织配置里写的域名和实际访问的地址对不上，就会出现各种 TLS 握手失败。解决办法是把 crypto-config 相关的配置全部检查一遍，确认每个 Peer 和 Orderer 的地址都能在 hosts 里解析。FISCO BCOS 相对好一些，官方的一键脚本会帮你生成配置，出问题优先看 build 目录下的日志。
提示：环境搭建阶段，把每一步的操作和报错都记在文档里。后面重装环境时这份记录能救你半天时间。
5.2 合约与链交互的典型故障
| 现象 | 常见原因 | 处理办法 |
|---|---|---|
| 调用返回成功但查不到数据 | 交易只是提交，未等待上链确认 | 用交易回执判断，轮询或监听事件 |
| 报错"out of gas"类问题 | 合约逻辑里有循环或存储写入过多 | 拆分逻辑，减少链上存储，考虑链下计算 |
| 读接口正常，写接口失败 | 权限或账户配置问题 | 检查调用账户的权限、合约的访问控制 |
| 事件监听收不到 | 节点未开启事件推送，或监听启动晚于交易 | 先启动监听再发交易，检查节点配置 |
| 中文乱码 | 编码不一致 | 全链路统一 UTF-8，上链前明确编码方式 |
这张表里的第一条是我见过最多的坑。区块链的交易是异步确认的，提交成功不等于上链成功。你的后端接口必须在拿到回执之后才返回成功，否则前端显示成功了、数据库里却查不到，演示时极其尴尬。
5.3 演示环节的翻车预防
答辩演示最怕的不是功能少，是现场跑不起来。我的经验是准备三手：一手是完整系统在本地跑；二手是录好的演示视频，覆盖所有核心流程；三手是截图和测试报告，万一前两手都出问题，还能靠讲解撑住。
演示脚本要提前排练，控制在一分半到两分钟，只演核心路径，别去点边角功能。数据要提前造好，别现场录入，输入框里打字的时间足够老师失去耐心。
5.4 答辩现场的高频问题与回答框架
根据我旁听和收集到的经验，这几类问题出现频率最高：
"你这个系统如果参与方作恶怎么办？"——回答思路是分层说：链上数据篡改需要多数节点合谋，成本如何；链下数据造假靠什么机制约束（比如多方交叉验证、抽查、信誉机制）。坦诚说明哪些防不住，比硬说"绝对安全"可信得多。
"为什么一定要用区块链，普通数据库不行吗？"——这是必问题。回答的核心是"多方之间缺乏单一可信方"，如果你能举出具体的信任冲突场景，这个回答就成立了。
"你的创新点在哪里？"——别背开题报告上的话，用一句话说清楚"别人怎么做、我改了什么、效果如何"。
"性能怎么样，能支撑实际使用吗？"——诚实回答测试数据和使用边界，说明这是原型系统，不是生产系统，同时给出优化方向。
6. 避坑清单和几点个人体会
6.1 选题阶段最容易踩的四个坑
坑一：题目里的"基于"后面跟了太多东西。"基于区块链和物联网和人工智能的智慧XX系统"，这种题目一看就是拼凑的，评审会直接质疑你到底做了多少。一个系统解决一个核心问题，足够了。
**坑二：选了需要真实数据的题目，但拿不到数据。**溯源、风控、信用评估这类题目，如果数据是编的，实验结论就站不住。要么选一个你能自己造出合理数据的场景，要么换成不依赖真实数据的题目。
**坑三：依赖了不可控的外部服务。**有些同学的系统调用了某个在线接口或者依赖外部网络的测试环境，答辩当天服务不可用，整个演示就废了。凡是不能本地跑通的东西，都不要放进核心链路。
**坑四：和导师的预期错位。**有的导师希望你做偏理论的，有的希望你做偏工程的。开题前一定要和导师把"交付什么"这件事对齐，别自己闷头做了两个月，导师一看说方向不对。
6.2 时间管理上的实在建议
秋招和毕设撞车几乎是必然的，我的建议是把重活往前压。九月到十一月尽量把环境、闭环、核心功能做完，这三个月是效率最高的窗口期。等到十二月之后，各种事情挤在一起，写代码的状态会明显下降。
另外，不要等系统做完才开始写论文。系统设计章节在代码写之前就能写完大半，测试章节可以边测边写。很多人拖到最后两周集中写，写出来的东西逻辑是断的。
6.3 几个能让论文多加分的延伸点
如果你提前完成了主体工作，可以考虑这些扩展：给系统加一个完整的日志与审计模块，记录每一次链上操作的调用方和参数；做一次小规模可用性测试，找几个同学扮演不同参与方走一遍流程，收集反馈；写一份部署文档，把从零搭建的步骤整理清楚，附录里放上去，评审会觉得你做事有条理。
还有一个我特别推荐的小做法：在论文的"不足与展望"里，认真写清楚你的方案在什么条件下会失效。这不是自曝其短，恰恰相反，能准确说出自己方案的边界，说明你真的想明白了。我见过好几篇评价不错的毕设，都是在这一节写得格外扎实。
6.4 最后一点个人经验
带了这么几届看下来，做得顺的同学有一个共同点：很早就把"最小可演示的东西"做出来了，然后在这个基础上一点点加。做得不顺的，往往是前期调研做得很漂亮、技术方案设计得很宏大，但迟迟没有一行能跑的代码，最后时间不够只能草草收场。
区块链这个方向，诱惑太多，新概念层出不穷。本科毕设不需要你追前沿，需要你把一件事做完整、讲清楚、能复现。选一个你真正能跑通的场景，把数据模型设计明白，把异常流程想周全，把测试数据老老实实测出来，这篇论文就不会差。至于那些看起来很炫的方向，等读了研再碰也不迟。
