1. 选题逻辑为什么“SpringBoot货物物流管理系统”值得做1.1 从痛点切入传统物流管理的问题清单货物物流管理系统是典型的“业务驱动型”项目市面上现有的中小物流企业管理系统普遍存在几个通病订单靠Excel登记、运输靠电话沟通、仓库库存靠人工盘点、对账靠月底翻聊天记录。货物从下单到签收整个链路的数据散落在不同人手里出了问题想追溯要花大量时间找单据、问当事人。如果你正在选毕业设计题目或者想做一个能写进简历的SpringBoot练手项目“货物物流管理系统”这类题目的好处在于业务场景贴近真实世界功能边界清晰天然适合用SpringBoot生态去落地并且能覆盖权限、缓存、流程、报表等多个高频技术点。从另外一个角度看物流系统的复杂度处在“刚好能撑起一篇开题报告”的位置。太简单的系统比如图书管理写不出深度太复杂的系统比如电商中台又超出个人开发者的实际承担能力。货物物流管理系统恰好落在中间地带既有订单、车辆、司机、仓库等多个实体之间的关联关系又有运输状态流转、库存变动、费用结算等业务规则适合用来展示你对需求分析、数据库设计、接口规划的理解。1.2 系统定位与核心价值做好这个题的关键是先把“物流管理系统”这个词拆成“货物”和“物流”两个维度去理解。“货物”维度关注的是物品信息、数量、重量、体积、货值“物流”维度关注的是运输工具、路线、节点、时间、费用。系统要解决的核心问题就是把这两个维度串成一条可追踪的链路客户下订单、仓库按订单备货出库、调度指派车辆和司机运输、收货方签收确认、财务根据运单结算。如果你在开题报告里把这层理解写清楚评审老师一眼就能看出你对题目的把握程度。系统最终呈现出来的价值不只是“把纸质单据变成电子单据”而是让每一票货的当前位置、当前状态、预计到达时间、历史轨迹都有据可查让管理者能在同一张看板上看到订单量、运输完成率、仓库库存周转情况。这就是物流管理系统区别于普通信息管理系统的核心差异。1.3 谁适合拿这个题做毕业设计或练手我个人建议三类人重点关注这个题目。第一类是计算机相关专业、需要完成毕业设计的学生这个题技术栈主流、业务复杂度适中、工作量可控开题报告和答辩都相对好讲。第二类是自学SpringBoot想找项目练手的开发者物流系统涉及的模块多但每个模块都不算深适合用来串联SpringBoot、MyBatis-Plus、Redis、JWT这些技术。第三类是工作中需要做企业内部物流管理工具的开发人员本文后半部分的表结构设计和状态流转方案可以直接参考。当然这个题目也有一些“劝退”点需要提前说明。如果你完全没接触过Maven、MySQL、Postman这些基础工具前期光是搭环境就会消耗不少时间如果导师对系统要求很高比如必须对接GPS定位、必须做多租户隔离那这个题的工作量会明显上升。所以选题之前先评估自己的时间和技术基础别只看着“物流”两个字就想当然觉得简单。2. 技术选型与架构设计把架子搭稳2.1 后端核心框架SpringBoot 2.x 还是 3.xSpringBoot版本选择是很多人容易纠结的地方。我建议如果你做毕业设计或者企业内项目优先用SpringBoot 2.7.x原因有三个资料多遇到问题搜得到兼容性好网上大部分开源组件和现成代码都是基于2.x写的Java版本要求宽松8或11都能跑。SpringBoot 3.x虽然已经稳定但底层是Jakarta EE部分老教程里的javax包名需要替换对新手不太友好如果不是为了写“技术先进性”那部分没必要在一开始就上3.x。SpringBoot在这个系统里承担的角色可以理解成一个“万能插座”。它负责把数据库连接池、Web框架、事务管理、日志、JSON序列化这些基础设施自动配置好你只需要关注业务代码本身。这在物流系统的开发中非常实用因为物流系统的业务代码量大、实体类多如果天天折腾配置文件真正写功能的时间就被挤占了。2.2 持久层三件套MyBatis-Plus、MySQL、Druid持久层我推荐MyBatis-Plus搭配MySQL再加一个Druid连接池这是目前国内中小型项目最务实的组合没有之一。MyBatis-Plus对单表的增删改查提供了现成的BaseMapper像订单表、车辆表、仓库表这种基础实体几乎不用写SQL就能完成CRUD省下来的时间可以去处理物流系统里真正复杂的多表关联和状态更新逻辑。对于需要写SQL的复杂查询比如统计某段时间内各线路的货运量直接写XML或注解SQL即可灵活性足够。MySQL就是老老实实存数据的地方。开发阶段你可以用8.0以上版本字符集统一用utf8mb4避免中文和生僻字出现乱码。Druid连接池的作用是监控和连接管理你可以在它的监控页面看到当前有多少活跃连接、慢SQL是哪几条这个能力在答辩演示时能加印象分也能帮你快速定位SQL性能问题。2.3 缓存与权限Redis JWT 的搭配物流系统里有几个典型场景适合引入Redis。比如运输途中的轨迹点数据频次高、实时性强可以先写到Redis里等车辆到达节点后再批量落库再比如司机端App查询“我的待办任务”每次请求都查数据库其实无所谓但加上缓存之后响应速度会明显提升。登录状态本身也可以存Redis设置过期时间配合JWT做无状态认证。具体来说JWT负责“证明你是谁”Redis负责“记录你登录后有多少权限、会话什么时候失效”。登录成功后后端生成JWT返回给前端前端在请求头里携带后端每次收到请求先解析JWT再从Redis里拉取用户信息和权限列表。这里有个容易出问题的地方JWT一旦签发在失效前是无法手动作废的如果用户修改密码或被管理员禁用了旧的JWT依然能用。解决办法是在Redis里维护一个黑名单或者版本号每次校验时比对这个细节写进开题报告会显得你考虑很全面。2.4 流程引擎把Flowable用在物流业务里热搜词里出现“springboot使用flowable”不是偶然Flowable是SpringBoot生态里非常流行的轻量级工作流引擎而物流系统天然适合有工作流支撑。比如一张运单从“创建”到“审核”再到“分配承运车辆”中间有审批节点和条件分支再比如退货流程需要经过客服登记、仓库确认、质检、退款等多个环节。这些流程如果用普通的if-else写在代码里流程变化一次就要改一次代码而用Flowable之后可以把流程定义成BPMN文件部署后通过引擎驱动流转。在物流系统里我建议先别把Flowable用得太复杂只需要用它做两个事情第一订单审核和派单流程的状态推进第二异常件处理流程比如货物破损、拒收。把Flowable定义在状态变化比较频繁、参与角色较多的模块上既能体现技术亮点又不会让项目难度突然飙升。Flowable的集成方式比较简单引入flowable-spring-boot-starter配置好数据源然后部署bpmn文件即可。需要注意的坑是Flowable会自动创建大量ACT_开头的表开发环境随便但生产库一定要用独立的数据源避免污染业务表。2.5 环境准备与常用配置开发环境建议如下JDK 1.8或11Maven 3.6以上MySQL 8.0Redis 6.xIDEA。如果是做前后端分离前端建议选Vue2或Vue3加Element-UI/Element-Plus因为物流管理后台的页面都是典型的表格加表单Element系列组件最顺手。前端脚手架可以直接用vue-element-admin模板省去从零搭菜单、路由、权限拦截的功夫。核心的application.yml配置里有几点值得注意。数据源URL上要加useSSLfalse和serverTimezoneAsia/Shanghai否则容易出现时区报错。MyBatis-Plus的逻辑删除配置用logic-delete-field这样删除订单时执行的是update语句而不是delete数据还在库里后续要追溯历史数据很方便。Redis的key设计建议统一前缀比如logistics:user:token:{userId}、logistics:track:{orderNo}一看就知道这个key属于哪个模块。3. 功能模块拆解从下订单到签收的完整闭环3.1 订单中心物流单生成与状态流转订单中心是整个系统的入口核心表是“物流订单表”它记录的信息要足够完整订单编号、客户名称、发货人信息、收货人信息、货物名称、数量、重量、体积、运费、支付方式、下单时间、期望送达时间、订单状态、备注。这里的订单编号一定要用可读性强的规则生成比如“LOG 年月日 4位流水号”方便人工识别和排查问题。订单状态的流转是重点。我建议至少设计这些状态待审核、已审核(待派车)、运输中、已签收、已取消、异常件。待审核状态下订单可以修改或取消已审核后进入派车环节运输中状态下面可以再拆分为“待提货、干线运输中、派送中”这几个子状态用status字段加subStatus字段组合表示。很多做物流系统的初学者容易犯一个错把状态做成字符串存在数据库里代码里各种0“1”“2”满天飞后期维护非常痛苦。建议用枚举类统一管理状态值并且在代码里只允许通过状态流转方法改变状态不允许直接setStatus。3.2 运输管理车辆、司机、路线的一体化调度运输管理模块包含车辆信息、司机信息、运输任务、路线管理四块内容。车辆信息要维护车牌号、车型、载重、容积、当前状态空闲/运输中/维修中、年检日期司机信息要维护姓名、手机号、驾驶证号、从业资格证、当前状态运输任务是一张核心关联表把“订单”和“车辆/司机”绑定在一起一条运输任务下可以包含多个订单这就是“拼车运输”的场景。调度流程可以这样设计调度员在待派车订单列表中选择一个或多个订单点击生成运输任务选择空闲车辆和司机系统会自动校验车辆的载重和容积是否满足订单总重量和总体积要求校验不通过则给出提示。这个校验逻辑用MyBatis-Plus查询车辆信息后在Java代码里做比较即可不需要写复杂的SQL。运输任务生成后订单状态自动变为“运输中”司机可以在司机端看到自己的任务列表和货物明细。为了加分你还可以在运输任务表里增加一个trajectory字段存储最近一次上报的经纬度配合前端地图组件做一个简单的车辆位置展示。3.3 仓储管理入库、出库、库存盘点仓储模块在物流系统中是“货”的静止状态管理主要包含仓库信息、入库单、出库单、库存表、库存流水。仓库信息维护仓库名称、地点、管理员、可用面积入库单记录货物进入仓库的信息包括来源订单号、货物名称、数量、存放库位出库单则对应货物离开仓库发往客户或下一站的情况库存表保存当前每个仓库、每种货物的实时结存数量库存流水记录每一次库存变动的明细是后期对账和审计的依据。这里有一个非常关键的设计理念库存数据不能直接通过update库存表来实现“扣减”而是要先写入库/出库流水再去更新库存表。这样做的好处是每一笔变动都有据可查一旦库存对不上可以通过流水倒推找到是哪一笔操作出了问题。在我的项目里入库操作采用事务控制先插入入库单明细再更新库存表任何一步失败都整体回滚。出库操作则要额外校验库存是否充足避免出现负库存这种低级错误。如果你在开题报告里把这段逻辑写出来评委大概率会觉得你做过程序设计而不是在拼凑页面。3.4 用户与权限多角色管理物流系统涉及的角色不止一种至少包括系统管理员、订单客服、调度员、仓库管理员、司机、财务、客户。不同的角色看到的功能菜单和操作按钮应该不一样比如司机只需要看自己名下的运输任务和签收操作财务只需要看账单和报表客户则只能查看自己的订单状态。权限设计我推荐用经典的RBAC模型也就是“用户-角色-菜单/权限”三层结构。后端用Shiro或Spring Security都可以但如果你选择了JWTRedis的方案可以不走重型安全框架自己写一个拦截器基于注解RequirePermission完成接口权限校验。需要注意的坑是前端菜单和后端接口权限一定要联动。很多项目只做了前端路由拦截后端接口任何人拿着token都能调用这是非常严重的安全隐患。比如客户角色的用户绝对不能调用“创建运输任务”的接口这个约束必须在后端校验不能只靠前端隐藏按钮。3.5 数据可视化与报表答辩加分项物流系统天然的报表需求非常多每日订单量、运输完成率、各线路货量分布、仓库库存周转率、司机工作量排行、月度运费收入统计。这些数据如果只是单纯地查出来展示成表格效果一般但用柱状图、折线图、饼图画出来视觉效果会好很多答辩时也更容易讲出亮点。报表功能建议引入ECharts前端图表库后端只提供统计数据接口。统计SQL是个重点比如“统计最近7天每天的订单数量”可以用DATE_FORMAT(create_time, %Y-%m-%d)分组统计“各车辆运输次数排名”可以先按运输任务表分组再排序统计“仓库库存周转率”则需要结合入库流水和出库流水的数据计算比较复杂可以作为进阶功能放在“后续优化”里讲不一定要完整实现。4. 数据库设计核心表和字段用大白话讲清楚4.1 核心表结构与字段说明数据库设计是开题报告和后续开发中最重要的部分之一设计得好后面写代码会很顺设计得烂每写一个功能都会觉得别扭。下面我按“用户权限、订单业务、运输业务、仓储业务”四组来梳理核心表。用户权限组表名关键字段说明sys_userid, username, password, real_name, mobile, role_id, status, create_time用户表密码建议BCrypt加密存储sys_roleid, role_code, role_name, description角色表role_code如ADMIN、DISPATCHER、DRIVERsys_menuid, parent_id, menu_name, path, perms, menu_type菜单权限表perms对应后端接口权限标识sys_user_roleid, user_id, role_id用户角色关联表(如果用户与角色是多对多)订单业务组表名关键字段说明logistics_orderid, order_no, customer_id, sender_name, sender_phone, sender_address, receiver_name, receiver_phone, receiver_address, goods_name, goods_type, quantity, weight, volume, freight, order_status, pay_status, create_time, update_time物流订单主表logistics_order_logid, order_id, from_status, to_status, operator_id, remark, create_time订单状态变更日志表记录每一次状态变化运输业务组表名关键字段说明transport_vehicleid, plate_no, vehicle_type, load_weight, load_volume, vehicle_status, maintain_time车辆信息表transport_driverid, driver_name, driver_phone, license_no, qualification_no, driver_status司机信息表transport_taskid, task_no, vehicle_id, driver_id, task_status, start_time, end_time, create_time运输任务主表transport_task_orderid, task_id, order_id运输任务与订单的关联表一个任务下挂多个订单transport_trackid, task_id, lng, lat, location_desc, report_time运输轨迹点表记录车辆上报的位置仓储业务组表名关键字段说明warehouse_stockid, warehouse_id, goods_name, quantity, update_time库存表一个仓库一种货物对应一条记录warehouse_inboundid, inbound_no, warehouse_id, order_id, operator_id, remark, create_time入库单主表warehouse_inbound_itemid, inbound_id, goods_name, quantity入库单明细表warehouse_outboundid, outbound_no, warehouse_id, order_id, operator_id, remark, create_time出库单主表warehouse_outbound_itemid, outbound_id, goods_name, quantity出库单明细表warehouse_stock_logid, warehouse_id, goods_name, change_type, change_quantity, balance_quantity, related_no, create_time库存流水表change_type区分入库/出库/盘点4.2 状态机设计关键的流转控制状态机这个概念听起来唬人其实本质就是“定义好每个状态能往哪些状态走不能乱跳”。以物流订单状态为例待审核只能被取消或者被审核通过变成待派车待派车在调度生成运输任务后变成运输中运输中在收货人签收后变成已签收也可能被上报异常变成异常件异常件经过处理后可能恢复正常运输也可能进入退货/赔偿流程后关闭为什么必须强调状态机因为物流系统涉及多角色协作如果代码里没有约束一个客服可能把已签收的订单误操作成待派车整个流程就乱了。实际实现时我建议在后端Service层写一组状态流转方法比如cancelOrder(),reviewOrder(),assignTransport(),signOrder()每次流转前先校验当前状态是否合法再执行状态变更。你可以在这些方法里统一加Transactional事务注解并记录一条订单状态日志这样出了问题可以从日志里看到完整链路。4.3 接口设计示例与返回格式统一物流管理系统的接口可以按模块划分这里列几个典型的接口设计示例方便你写接口文档时参考。订单模块接口请求方法路径说明分页查询订单GET/api/order/page支持按订单号、客户名、订单状态筛选创建订单POST/api/order创建新的物流订单订单审核PUT/api/order/review/{id}审核并改变订单状态订单取消PUT/api/order/cancel/{id}待审核状态下才能取消订单详情GET/api/order/{id}返回订单基本信息、状态日志、关联运输任务运输模块接口请求方法路径说明生成运输任务POST/api/transport/task选择订单、车辆、司机生成任务运输任务列表GET/api/transport/task/page支持按状态、车牌号、司机姓名筛选上报轨迹POST/api/transport/track司机端上报当前经纬度签收PUT/api/transport/sign/{taskId}司机操作签收同时更新关联订单状态统一返回格式很重要我习惯用ResultT这个泛型类属性包括code、message、data。成功时code200业务异常时code4000系统异常时code5000。前端根据code做统一拦截比如登录过期返回code4010前端就跳转登录页。不要一个接口返回一种格式那个后期会让前端开发骂娘。5. 开题报告怎么写得像老手结构、篇幅与常见坑5.1 开题报告的标准章节与写作顺序既然项目标题里明确写了“开题报告”这部分我单独拿出来讲。正规的开题报告一般包含这几块内容选题背景与研究意义、国内外研究现状、研究目标与内容、技术路线与关键问题、预期成果与创新点、进度安排、参考文献。有些学校还会要求写“可行性分析”和“工作基础”视具体院系模板而定。写作顺序上我建议先写“研究目标与内容”再回头写“选题背景和研究意义”最后写“技术路线和进度安排”。原因是先写具体内容会让你更清楚这个系统边界在哪里写背景时不容易飘。很多学生习惯从头开始按顺序写写到研究意义时就开始堆砌“随着社会的快速发展”这类空话最后被导师批得改来改去。你如果先用一两句话说清“本系统要实现什么、面向谁、核心功能有哪些”整个报告的逻辑就会稳很多。5.2 研究背景与意义的写法拒绝空话研究背景要落到具体问题和数据上不要写“随着互联网技术的不断发展各行各业都在数字化转型”这种正确的废话。你可以写“目前许多中小物流企业的货物运输管理仍然依赖人工登记和电话沟通订单信息分散在多个Excel表格中车辆调度缺少统一视图货物运输状态无法实时反馈给客户导致货损货差追溯困难、客户满意度低。”这一段不需要引用多高级的理论但要把痛点一条条摆出来让读者觉得“确实需要这样一个系统”。研究意义分成理论意义和实践意义。理论意义可以落在“结合SpringBoot微服务思想和B/S架构设计一套适合中小物流企业的信息管理方案”实践意义可以落在“系统投入使用后能够减少人工登记工作量、提高订单处理效率、实现货物的全流程可追溯”。注意意义要和你后续做的功能一一对应别前半部分写“可视化大屏”后面功能模块里根本没有这个答辩时被问一下就露馅了。5.3 进度安排与工作量证明进度安排是开题报告里最容易被忽略但导师最爱看的板块。你不需要写得太笼统比如“第1-2周需求分析第3-4周系统设计”这样没有说服力。建议把进度细化到与功能模块对应例如第1周查阅文献、明确需求完成系统功能框图和数据流图设计第2-3周搭建开发环境完成数据库概念设计和逻辑设计建表并准备初始数据第4-5周完成基于SpringBoot的后端基础框架实现登录认证、用户权限管理模块第6-8周完成订单管理模块包括订单CRUD、审核流程、订单状态流转与日志第9-10周完成运输管理模块包括车辆司机管理、运输任务生成、轨迹上报接口第11-12周完成仓储管理模块包括入库、出库、库存查询与库存流水第13周完成数据统计报表模块前后端联调修复Bug第14周完善系统测试编写毕业论文初稿第15周修改论文准备毕业答辩这里有一个算工作量的技巧把每个模块拆出来写占据的篇幅自然就上去了导师也会觉得你的工作量足够饱满而不是泛泛地说“实现了一个系统”。如果你已经开发了一部分可以直接按照实际进度调整这个表格但注意写进报告的内容要和答辩时展示的功能一致。5.4 答辩高频问题与应对话术开题答辩时老师最常问的问题集中在几个方向为什么选SpringBoot而不用SSH老框架或微服务全家桶数据库为什么这么设计订单状态流转异常怎么处理Flowable用来解决什么问题。我先针对这几个提前做准备。“为什么选SpringBoot而不用别的框架”你可以说SpringBoot简化了配置内置了Tomcat生态丰富适合快速构建中小型独立系统如果问“为什么不拆微服务”就答“物流管理系统的用户规模和数据量尚且处于单机应用可承担的范围内使用SpringCloud会增加运维复杂性没有必要”这显得你有技术判断力而不是在追潮流。“数据库为什么这么设计”要结合具体表讲比如“订单和订单日志拆成两张表是为了记录状态流转历史方便追溯每一次变更”“运输任务和订单通过关联表关联是因为一个任务可以拼多个订单如果一对一做在主表里就很难支撑拼车场景”。这类回答要基于你自己的表结构平时画好ER图、背熟表字段答辩时心里有底。“如果订单状态流转出错怎么办”这个问题考察的是异常处理意识你可以回答“在后端Service层做状态合法校验所有状态变更都通过统一方法完成并且记录日志同时在数据库层面放一个状态字段的默认约束配合事务回滚保证不会出现脏数据”。6. 开发实录SpringBoot配置和Flowable踩坑记录6.1 SpringBoot热部署与多环境配置开发阶段一定要配置热部署devtools改完代码自动重启能省很多手动重启的等待时间。引入依赖后在application.yml里设置spring.devtools.restart.enabled: trueIDEA中把自动构建打开即可。需要注意热部署在小项目里好用如果你的项目越来越大了频繁重启反而拖慢开发节奏那时可以直接删掉这个依赖手动重启更可控。多环境配置也是一个很实用的习惯。把application.yml拆成application-dev.yml和application-prod.yml启动时加上--spring.profiles.activedev参数选择对应环境。dev环境连接本地数据库不用密码或者弱密码prod环境用独立数据库、独立Redis防止连错库导致数据误操作。这个习惯从项目一开始就养成后面部署上线时会省心很多。6.2 MyBatis-Plus分页与自动填充MyBatis-Plus的分页查询需要配置一个PaginationInnerInterceptor插件很多人忘了这一步导致分页不生效或者返回全量数据。配置方法很简单在MybatisPlusConfig类里注册MybatisPlusInterceptor Bean并添加分页插件。分页查询时调用Page对象作为第一个参数返回的IPage里就有total和records。自动填充功能也非常适合物流系统。数据库的create_time和update_time字段不用每次手动set可以定义一个MetaObjectHandler实现类在insert时自动填充create_time和update_time在update时自动填充update_time。这个功能还有一个进阶用法订单审核时自动填充operator_id操作人ID能从审计角度知道“这个订单是谁审核的”。6.3 Flowable集成时的几个典型问题Flowable集成到SpringBoot其实不算难引入flowable-spring-boot-starter后它自己会创建表结构开发环境直接让它自动建表就行。但有几个问题你八成会遇到我提前和你说。第一个问题是Flowable默认的表前缀是ACT_会和你的业务表混在同一个数据库里如果你用Druid的监控页面看SQL会发现大量AC开头的表。不是Bug是Flowable自己的一套数据模型不用害怕。第二个问题是自动部署BPMN文件路径默认会扫描classpath下的processes目录你把bpmn文件放这个目录就能自动部署但修改了bpmn文件之后要注意版本号变化否则引擎会报“流程定义不存在”。第三个问题是Flowable的流程实例和业务表如何关联建议在业务表里增加一个process_instance_id字段启动流程时拿到流程实例ID回填到业务表里后续查询流程状态就靠这个字段关联。6.4 物流系统的自测清单开发完主体功能后不要急着写论文或者交差先按下面的清单过一遍。测试不是为了走形式而是真的能发现很多隐藏问题。订单从创建到审核到派车到签收走一遍完整流程观察状态变化和日志记录是否正确物流订单创建时同时发生重复点击提交按钮的情况看是否会产生重复订单接口层面要做幂等处理库存充足和库存不足两种场景下出库操作确认不足时系统能拦截并给出错误提示两个不同角色登录同一个客户端A角色的菜单和按钮是否真的不可见后端接口是否真的禁止访问司机上报轨迹接口传入非法的经纬度数值检查后端参数校验是否生效同时对同一个订单发起取消和审核请求看事务和状态校验是否能拦截住其中一个使用Postman或JMeter对订单列表查询接口做一次简单压力测试看分页查询在数据量几百条时响应是否还在预期范围内写到这里这个题目的开发思路和开题报告要点基本都聊完了。我个人在实际操作中的体会是SpringBoot货物物流管理系统最大的价值不是技术本身有多深而是逼你把需求分析、表设计、状态流转、权限控制这些真实项目里必踩的环节完整走一遍。你把这个项目的思路讲清楚了后面无论换什么管理系统题目框架都是相通的。如果时间允许建议后续往这几个方向扩展对接电子地图做运输路线可视化、引入消息队列处理订单高峰期的数据写入、增加移动端司机小程序。把这几个点做完这个项目放在作品集里就相当能打了。