★ FEATURED ARTICLE 1. “有光”这个选题是怎么定下来的摄影分享网站的毕设定位每年到毕设选题季计算机专业的群里都会冒出同一个问题SpringBoot到底做什么题目好过审、好答辩、还能写进简历里我当年就是这么被折磨过来的所以看到“基于SpringBoot的‘有光’摄影分享网站系统毕业设计”这个题目时第一反应是——这题选得还算聪明。先给还没定题的同学拆一下为什么这个题目能打摄影分享网站本质上是“内容社区”的简化版而下到课程设计、上到互联网大厂面试里内容社区类系统几乎覆盖了Web开发的所有核心知识点。用户体系、文件上传、内容展示、互动行为、搜索检索、权限控制这是每个后端开发都躲不开的六大基本功恰好都能塞进一个摄影分享网站里。换句话说你做完这个题不只是交差而是真的把一套Web后端的知识骨架过了一遍。“有光”这个名字本身也有讲究。摄影里讲“追光”一个摄影作品分享平台叫“有光”品牌感一下就出来了比“XX摄影网站”“基于Java的图片管理系统”这种名字好太多了。毕设答辩时导师第一个问题大概率是“为什么做这个题目”这时候你可以说一方面摄影内容天然适合视觉化展示系统的核心功能边界清晰另一方面围绕图片这一核心实体可以自然延伸出用户、评论、点赞、收藏等社区互动模型复杂度适中本科阶段能完整实现也能讲清楚设计思路。再聊聊选题的避坑逻辑。SpringBoot毕设题在市场上多如牛毛——图书管理、学生管理、班级管理、仓库管理被做烂了不说功能上就是几张CRUD表凑出来答辩时压根没什么可讲的。“有光”这类内容型项目的好处在于它有“看得到摸得着”的业务场景页面有作品展示、有图片瀑布流后端有上传处理、有访问控制、有搜索排序数据库关联也比单纯的管理系统复杂有用户、作品、评论、点赞、收藏、关注等多张业务表之间的关系。工作量容易堆起来凑字数、凑功能都方便但反过来也是真能学到东西。我还得提醒一句毕设选题一定要看自己的实际水平和答辩要求。如果你的学校答辩组喜欢看“管理系统”那你做一个带基本发布、浏览、删除功能的摄影分享网站也完全够因为这套系统的核心功能——用户登录注册、作品上传发布、个人中心、分类浏览——本身就覆盖了管理类系统的全部基本操作。如果你还想往简历上写那就在这个基础上把“显示图片瀑布流”“图片搜索”做扎实这一套下来你已经超过同批次大半的选题了。2. 技术栈选型为什么是SpringBoot而不是其他组合确定了“摄影分享网站”这个业务方向以后接下来的问题是技术栈怎么定。这里我先说结论也给当时自己踩过的坑做个复盘我这个项目最终用的SpringBoot 2.7.x MyBatis-Plus MySQL 8.0 Redis MinIO前端是Vue 3 Element Plus。前端后面细说这一章重点讲后端为什么这样选。2.1 SpringBoot版本用2.7.x别碰3.x我知道现在SpringBoot官网一进去推荐的已经是3.x了但如果你是在校学生做毕设我用亲身经历劝一句SpringBoot 2.7.x比3.x更适合你。原因有两点。第一3.x是基于Jakarta EE 9的连javax.servlet都改成了jakarta.servlet网上搜出来的教程、博客、甚至是老师给的参考代码百分之七八十还停留在2.x时代照抄会抄出一堆环境错误光排错就能耗掉你好几天。第二3.x强制要求JDK 17而很多学校实验室电脑装的是JDK 8你装完发现跑不起来得先给导师解释半天为什么换Java版本——这种麻烦完全没必要。我自己在项目里用的是SpringBoot 2.7.142.7系列最后一个小版本配的JDK 8。这个版本生态成熟无论是MyBatis-Plus、Spring Security还是各种工具包几乎没有兼容性问题。如果你的电脑上已经装了JDK 17那也可以使用2.7.x它对JDK一直是向下兼容的。总之除非你导师明确要求用3.x否则就是2.7.x JDK 8的稳妥组合。2.2 持久层框架MyBatis-Plus做CRUD省时间还不丢性能持久层我选了MyBatis-PlusMP这是国内Java圈子里的“毕设神器”没有之一。它最大的价值是内置了BaseMapper和IService这套泛型接口基础的增删改查、分页查询、条件构造全都不用手写SQL直接继承就能跑。做毕设最缺的是时间这套东西能把纯CRUD的开发量压缩到原来的三分之一左右。但我要特别强调一点用MyBatis-Plus不等于不写SQL。当时我做“用户关注”和“作品信息流”这两个功能时还是用Select注解手写了一部分多表查询和聚合查询。原因很简单——MP的QueryWrapper虽然有join方法leftJoin但复杂查询里拼接起来可读性差改个条件要盯半天反而没直接写SQL清晰。真实项目里也会遇到同样的问题框架能解决80%的常规操作剩下20%的复杂SQL该手写就手写不必为了“用框架”硬套。2.3 数据库与缓存MySQL 8.0 RedisMySQL 8.0是默认选项不多说。这里想聊聊Redis。摄影分享网站里有两个场景非常适合用缓存一是首页信息流的推荐列表二是热门作品的排行榜。当时我的做法是把“最新作品列表”的查询结果缓存到Redis的String类型里key设计成feed:latest:page:{pageNum}设置5分钟过期。信息流内容更新频率不算高5分钟的短暂延迟用户根本感知不到但数据库访问量能降一大截。点赞数和收藏数用Redis的Hash存储like:count:{workId}先用incr累加然后定时任务每10分钟把增量刷回MySQL。这样点赞的接口响应速度极快给用户“秒赞”的体验。这个设计在答辩时是很加分的——你既点了“缓存技术”这个关键词又讲清了“缓存和数据库如何保持一致”的实现细节比空喊一句“我们项目用了Redis”强得多。不过Redis的使用也要克制不要所有数据都往里塞。作品列表、评论区这些低频变化的数据直接查MySQL就行。缓存这东西用得不好就是“缓存穿透”“缓存雪崩”的坑。我当时写的是“旁路缓存”策略Cache Aside Pattern读的时候先查缓存没有再去查库并回填写的时候先更新数据库再删除缓存。这是最稳妥、最容易跟评委讲清楚的模式。2.4 图片存储MinIO替代本地目录和OSS的取舍先说个所有毕设都会踩的坑——图片到底存哪里。最省事的方案是把图片传到项目根目录下的upload/文件夹数据库里存个相对路径。但这套方案有两个致命问题第一打包部署后上传路径和运行路径会错乱图片经常丢第二项目重启时临时文件可能被清理你上午传的图下午就404了。我当时换了MinIO。MinIO是一个开源的、兼容Amazon S3协议的对象存储服务本地用Docker或者直接下载解压就能跑起来不花钱、不依赖外网服务。图片统一传到MinIO的某个bucket里数据库存的是http://localhost:9000/photo/xxx.jpg这样的完整URL路径。这样无论是本地开发还是部署到云服务器图片地址都是稳定的不会因为重启就把资源搞丢。为什么不用阿里云OSS如果你是自己做练习OSS要实名认证、要充钱用完还得担心欠费。MinIO跑在本地完全免费而且核心API的调用方式和OSS几乎一致——都是putObject、getUrl、removeObject这套S3风格接口。做完这个毕设你顺手也把对象存储的通用技能学会了以后真上云也就是换个配置的事。3. 数据库设计摄影社区的核心是表之间的关系数据库是毕设的地基地基没打好后面写多少代码都是空中楼阁。摄影分享网站涉及的数据量并不大但表设计却很考察逻辑因为这是一个典型的“内容社交”型系统。我先说几个核心表再说当时踩过的关系设计坑。3.1 核心表结构一览我最终建了8张表用户表、作品表、分类表、评论表、点赞表、收藏表、关注表、浏览记录表可选。下面挑关键字段说用户表user)字段名类型说明idbigint主键自增usernamevarchar(50)登录名唯一passwordvarchar(100)BCrypt加密后的密码nicknamevarchar(50)昵称展示用avatarvarchar(255)头像URL存MinIO路径biovarchar(255)一句话个人简介created_timedatetime注册时间密码用BCrypt加密存这是Spring Security自带的标准加密器答辩时如果评委问“密码为什么不是明文存的”你答“BCrypt加盐哈希即使数据库泄露也无法还原原始密码”基本就过关了。作品表photo)字段名类型说明idbigint主键user_idbigint上传者ID关联用户表titlevarchar(100)作品标题descriptiontext作品描述可空image_urlvarchar(255)图片的MinIO访问路径category_idbigint所属分类IDlike_countint点赞数冗余字段collect_countint收藏数冗余字段statustinyint0-正常 1-已删除created_timedatetime上传时间like_count和collect_count是冗余字段目的是查询作品列表时不需要每次join统计点赞表直接排序就行。这种设计叫“空间换时间”在内容社区系统里非常常见也在答辩里展示了你对“读写性能取舍”的理解。评论表comment)字段名类型说明idbigint主键photo_idbigint所属作品IDuser_idbigint评论者IDcontentvarchar(500)评论内容parent_idbigint父评论ID支持楼中楼回复0表示顶级评论created_timedatetime评论时间点赞表、收藏表、关注表的思路都是“一个用户对另一个实体的一次操作记录”用联合唯一索引保证“一个人只能赞一次”比如unique_key(photo_id, user_id)。这个唯一索引设计非常关键如果没有它你接口里得先查一下是否已点赞再决定能不能插入多一次查询不说并发下还容易重复插入。有了唯一索引直接插捕获到DuplicateKeyException就能知道“已经点过赞了”。3.2 别做“用户表存关注列表”这种反范式设计这部分讲讲真实踩坑。一开始我天真地想既然关注关系是“一对多”要不要干脆在用户表里加一个字段存“我关注的用户ID列表”比如用逗号分隔的字符串后来才发现完全不是那么回事——查“我的粉丝列表”变成噩梦你得遍历所有用户再挨个用LIKE匹配字段里的ID串。数据量一上来就是全表扫描慢得想砸电脑。正确做法就是建一张“关注表”一行记录一个关注关系它表达的是“谁关注了谁”这个事实和用户表、被关注用户表之间只用外键和索引关联。这也是为什么内容社区设计里有“关系表”这种独立存在的类型——它不是业务主实体的附属而是业务关系本身的建模。所以毕设里凡是出现“一个用户和另一个用户”“一个用户和一个作品”这样的关系就拆一张关系表出来准没错。3.3 分页查询的索引策略作品信息流的分页我用的MP自带分页插件PaginationInnerInterceptor它会在SQL后自动拼接LIMIT语句。但分页查询最容易出现的性能瓶颈是OFFSET太大时MySQL要扫掉前面所有记录。我的缓解方案是用WHERE created_time 游标值 ORDER BY created_time DESC LIMIT 10这种“游标分页”也叫keyset分页而不是LIMIT 100000, 10。这样做在毕设数据量下体验不出区别但你写进文档里、答辩时提一句“说明你考虑过数据量增长后的系统瓶颈”水平一下就拉开了。4. 核心功能拆解从上传到信息流每个模块的实现逻辑功能模块是评委最容易逐个追问的地方。这里挑三个最有代表性的功能把当时的实现思路和核心逻辑完整过一遍你照着做项目时能少走弯路。4.1 作品上传先传文件再存记录顺序不能反上传接口看起来简单但有个顺序问题很容易被忽略。我的第一版实现是前端传文件后端创建一条作品记录再把文件写入MinIO最后把URL更新回去。结果一旦MinIO写入失败数据库里就多出一条没有图片地址的脏数据。调了好几次最后把流程固定成这个顺序后端接收MultipartFile检查文件类型只允许jpg/png/webp和大小不超过10MB。生成唯一文件名格式是userId_时间戳_随机数.jpg避免重名覆盖。先把文件putObject到MinIO拿到访问URL。URL拿到后再插入作品表此时image_url已经有值。如果第4步失败调用removeObject把刚上传的文件删掉回滚。这套“先存储、后入库失败回滚”的流程不只是毕设任何真实的文件上传功能都应该这么写。我在文档里特意画了这条流程线答辩时也被评委表扬“考虑到了数据一致性”。另外有个细节文件名校验。原来我用的是originalFilename直接拼上去比如photo.jpg后来发现中文文件名或者带空格的文件名会导致URL访问异常所以才改成用UUID或者时间戳加随机数作为文件名。这个坑很小但做毕业设计时碰到过一次印象特别深。4.2 信息流与推荐列表按时间排序按点赞数加权“有光”的首页不能只是所有作品按时间倒序排——那样太单调了评审老师打开网站会觉得“这不过是个相册”。我的方案是首页分成两个Tab“最新”和“热门”。最新WHERE status 0 ORDER BY created_time DESC直接用游标分页翻页。热门ORDER BY like_count DESC, collect_count DESC, created_time DESC一个SQL嵌套排序就搞定点赞多的、收藏多的排前面热度相同时新的在前。这还不够我加了一个首页大图轮播功能后台把指定作品“置顶”置顶标识存在数据库里前端先查置顶作品展示轮播再往下走信息流列表。这个功能看起来简单但让首页有了“运营位”的概念整个网站瞬间从一个“功能列表”变成了一个“产品”。写代码时的注意点是排序字段一定要加上索引否则数据量几百条时感觉不明显数据量上万后接口响应时间会成倍增长。我当时在created_time和like_count两个字段上各建了一个普通索引虽然数据量不大但这种“设计和实现走正道”的习惯是能写进文档里展示的。4.3 点赞与收藏防重复、做总量点赞和收藏在数据库层面是一回事一张关系表加一个计数。但在接口层面一定要处理“幂等”的问题。所谓幂等就是同一个用户重复点击同一个按钮效果等同一次点击不会重复插入。我当时的实现是直接用唯一索引兜底 业务层先判断Override Transactional(rollbackFor Exception.class) public String likePhoto(Long userId, Long photoId) { // 1. 先查是否已点赞 LambdaQueryWrapperPhotoLike wrapper new LambdaQueryWrapper(); wrapper.eq(PhotoLike::getUserId, userId).eq(PhotoLike::getPhotoId, photoId); PhotoLike existing photoLikeMapper.selectOne(wrapper); if (existing ! null) { throw new ServiceException(您已经点过赞了); } // 2. 插入关系记录 PhotoLike likeRecord new PhotoLike(); likeRecord.setUserId(userId); likeRecord.setPhotoId(photoId); photoLikeMapper.insert(likeRecord); // 3. 更新作品的点赞数字段1 photoMapper.increaseLikeCount(photoId); return 点赞成功; }increaseLikeCount对应的SQL是UPDATE photo SET like_count like_count 1 WHERE id #{id}这种“自增更新”而不是“先查再设值”的做法避免了并发下脏写的问题。如果你用like_count 查出来的值 1两个请求同时读到100同时写回101其中一个赞就丢了。这类并发问题虽然毕设不会真的被高并发冲击但代码里用对写法答辩时能讲得理直气壮。4.4 搜索结果走MySQL的模糊匹配加MySQL全文索引搜索这个功能一开始用的是LIKE %关键词%数据少时没问题但我总感觉“太敷衍了”。后来看SpringBoot整合Elasticsearch的资料发现要把ES集成进来先得维护一套和MySQL同步的逻辑对毕设来说太重了。我最后用了MySQL内置的全文索引FULLTEXT来搜标题和描述关键词可以按相关度排序。这套方案不需要额外引入组件代码量也非常少SELECT * FROM photo WHERE MATCH(title, description) AGAINST (#{keyword} IN NATURAL LANGUAGE MODE)但说实话MySQL全文索引对中文分词支持一般。如果你不想折腾全文索引老老实实用LIKE %keyword%也能交差。毕设的系统数据量撑不起什么搜索压力评委在意的是你有没有“搜索的想法”——比如你想过用NGram全文解析器、想过把搜索日志记录下来分析用户偏好这些思路本身就占分。我最终文档里选了完整方案MySQL全文索引 分页 搜索关键词加粗高亮完全没有引入额外的搜索引擎工作量和复杂度都可控。5. 前端与接口设计Vue 3动线构图前后端联调的心得后端接口写得再漂亮前端页面丑得要命评委打开演示那一刻还是会印象分大跌。摄影网站尤其吃视觉前端这关必须花心思。5.1 技术选型Vue 3 Element Plus Axios我选了Vue 3 Vite Element Plus。为什么Vite因为开发时热更新快改一个组件页面秒级刷新做毕设时反复微调样式体验好得多。Element Plus就直接用组件库里的卡片Card、瀑布流布局组件、分页组件、上传组件界面干净不用手写太多CSS。有一个关键点如果你完全没学过Vue这会是额外的时间成本。但好在Vue 3的基本用法——组件、路由、响应式数据、Axios调用——只要花两三天就能上手毕设项目也不需要太复杂的组件设计。如果你时间真的很紧也可以直接用Thymeleaf模板后端一次性渲染牺牲一些交互体验但功能上完全够用。我的建议是有精力就Vue没精力就Thymeleaf别在前后端分离的形式上过度内耗。5.2 前端页面结构“有光”的前端页面我是按这个结构组织的首页导航栏 轮播图 分类Tab 作品瀑布流最新/热门 分页。作品详情页大图展示、作品描述、作者信息、点赞数、收藏数、评论区可回复。个人中心我的资料、我的作品、我点赞的、我收藏的、我关注的、我的粉丝。后台管理页作品审核/删除、用户管理、分类管理、数据统计上传量曲线。个人中心这个模块容易被忽略但它是考核“这个系统完整度”的关键——因为只有作品上传和浏览的网站根本没有“用户去留”的概念。有了个人中心用户体系才真正闭环。前端调用后端接口时统一用Axios封装// request.js import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器自动携带token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) // 响应拦截器统一处理401等异常 request.interceptors.response.use( response response.data, error { if (error.response.status 401) { router.push(/login) } return Promise.reject(error) } )接口路径的设计遵循的是RESTful风格比如GET /api/photo/page、POST /api/photo、DELETE /api/photo/{id}、POST /api/photo/like/{id}。前后端联调时接口文档一定要先写清楚——我当时用Apifox一个类似Postman的工具先把所有Controller方法和参数列出来前端再照着写调用两天内就把整个网站的接口全跑通了。6. 登录鉴权与权限控制JWT Spring Security别硬啃但要理解毕设系统里登录注册肯定绕不开但完全自主研发一套会话系统又太累。我当时用了经典方案Spring Security JWT。6.1 JWT的工作原理一句话用户登录成功后后端签发一个JSON Web Token一串加密字符串前端存到localStorage里。之后每次请求在请求头里带上Authorization: Bearer token后端校验签名和过期时间知道“这是哪个用户的请求”。相比传统的Session方案JWT是无状态的服务端不需要存会话信息特别适合前后端分离的架构。6.2 Spring Security配置要点Spring Security的配置容易劝退人但核心配置其实就那么几块放行哪些接口、拦截哪些接口、自定义校验逻辑。Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests() .antMatchers(/api/user/login, /api/user/register, /api/photo/page, /api/photo/detail/**).permitAll() .anyRequest().authenticated() .and() .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); }需要注意的是作品浏览接口要放行否则未登录用户连网站首页都打不开演示的时候就很尴尬。后台管理的接口要拦截严格一点比如/api/admin/**必须要有管理员角色才能访问。JWT签发时我塞了userId和username进去每次请求从 token 里解析出 userId配合一个ThreadLocal存储当前用户信息这样在Controller层随时能拿到当前用户对象非常方便。这套设计的完整链条是用户登录 → 验证用户名密码 → 签发JWT。前端每次请求带上token。后端JWT过滤器解析token → 设置当前用户上下文。Controller通过UserContext.getCurrentUserId()获取当前操作人ID。这套链路理解了以后你会发现所有“需要知道当前登录人”的功能——上传作品、点赞、评论、收藏——都只需要拿一个ID代码写起来特别顺手。6.3 密码安全BCrypt加盐是底线用户表的密码绝不能是明文。我当时用Spring Security自带的BCryptPasswordEncoder做加密注册时加密入库登录时用matches()方法比对。BCrypt自动加盐同一密码每次加密结果都不一样破解成本极高。这是行业标准做法也是毕设里底线级的规范。答辩时如果老师问“密码怎么存的”你这一句话就能得分。7. 部署与演示本地能跑还不够云服务器部署逻辑要懂很多毕设项目在本地IDE里跑得通但答辩环境一变——老师的电脑没有MySQL、没装Redis、IP地址不同——就当场翻车。为了避免这种“答辩事故”我建议最晚在答辩前两周把项目完整部署到一台云服务器上。7.1 部署三步打包、配环境、起服务我的方案是用Docker Compose一键部署后端、MySQL、Redis和MinIO。虽然学校不会要求你精通Docker但会用docker-compose.yml编排环境能给导师留下“工程素养”的印象。部署环境清单如下一台2核4G的云服务器Linux系统Ubuntu 22.04。安装Docker和Docker Compose。后端打jar包mvn clean package -DskipTests用Java命令启动java -jar photo-0.0.1-SNAPSHOT.jar --spring.profiles.activeprod。前端用npm run build打出的静态文件部署到Nginx同时Nginx配置反代/api/到后端8080端口。配置文件在本地是application-dev.yml服务端用application-prod.yml两者最大的不同是数据库地址、Redis地址和MinIO地址。我一开始就吃了硬编码的亏把localhost写在Java代码里结果部署到服务器后图全挂了。后来统一改成Value(${storage.endpoint})这种方式按配置文件注入换环境只需要改配置再也不用改代码。7.2 演示前必须要做的一轮自查我总结了一份答辩前的演示自查清单全是我自己踩过坑换来的作品图片是否全部能正常访问换个浏览器再测一遍防止缓存导致看到旧图。首次注册新用户的整个流程注册-登录-上传-详情页是否畅通管理员账号能否登录后台管理系统网络断开时前端有没有兜底提示这个不要求但做了更完整。服务器内存是否够用Redis和MySQL同时跑起来2G内存比较紧张4G最稳。演示用的数据是否预先准备至少准备10~20张作品图片和3~5条评论页面才显得有人气而不是“刚上线”。关于图片内容建议用自己的原创图片或者从无版权图库找一些免费素材。如果你在演示时展示一堆带水印的网图美观度和观感都会受影响。7.3 文档与答辩材料的组织论文和工作量文档是毕设的另一半。我的经验是文档不要从“创建项目”开始写而要从“为什么做这个系统”开始需求分析这个网站解决什么问题目标用户是谁有哪些核心需求系统设计整体架构图前后端分离、数据库ER图、功能模块图。详细设计核心功能的前后端流程比如上传流程、点赞流程、JWT鉴权流程。系统实现按模块展示核心代码配上关键说明。测试与运行测试用例设计和运行结果截图。总结与展望说一下系统的不足比如搜索性能和后续可以改进点比如接入推荐算法。画架构图和ER图不要用花哨的工具我用的ProcessOn画完直接导出图片贴到文档里。逻辑清晰比图好看更重要。8. 做完这套毕设你真正带走的是什么东西最后说说我做完“有光”之后的真实感受。坦白讲这个项目放在整个市场里不算什么“高级系统”——它没有微服务、没有消息队列、没有容器编排就是个老老实实的单体应用加几个常规组件。但恰恰是这样它让我把SpringBoot从“照着视频敲代码”变成了“自己设计一套业务系统”。做完之后我才意识到毕设的价值从来不是“题目本身多牛”而是你借着这个题目把一条完整的技术链路亲手走了一遍。你在做“有光”的过程中掌握的那些底层能力——怎么设计数据表、怎么处理文件上传的异常、怎么写幂等的点赞接口、怎么配置安全框架、怎么把一套系统部署到线上——这些东西是通用的并不会因为换了下一个项目就没用了。如果你正在做或者准备做这个题目我可以给你三个建议。第一盯住核心功能不要一上来就想着做智能推荐、图像识别这种花活先把上传、展示、互动、个人中心这条主线做扎实跑通了再谈增值功能。第二每一处代码里都要能说清楚“为什么这么做”这比代码本身更能让你在答辩里站稳。第三不要把时间全花在代码上给网站准备一批有质感的摄影作品让上传后的页面真正“有光”演示时第一眼的冲击力远比十页文档有用。我个人在实际操作中的体会是这种内容型系统的毕设最容易出彩的地方不是某个技术有多难而是它整体完成度是不是像一个“真能上线用的产品”。“有光”这个名字很有画面感你把它做成一个真正有内容、有社区感的网站它自然会成为你简历里值得一提的项目。
阅读完成 · 觉得有帮助？
