先交代一下背景。我家那只布偶猫刚接回来的时候才两个多月当时的体重、疫苗时间、驱虫周期全靠手机备忘录硬记相册里翻照片才知道它什么时候变圆了不少。后来和几个养猫养狗的朋友一聊发现大家都有类似的困扰宠物从小到大变化很快但市面上能用的记录App要么广告太多要么功能冗余到让人不想打开。于是我决定自己动手用Python的Flask写后端Vue做前端在PyCharm里从零搭了一套宠物成长监管系统。这篇文章就是整个项目的设计与实现复盘包括数据模型怎么设计、后端接口怎么组织、前端页面怎么搭以及联调阶段那些足以把人逼疯的坑。如果你也在用Flask练手或者正在纠结毕设/个人项目怎么选型这篇文章应该能让你少走不少弯路。1. 为什么是FlaskVue而不是Django全家桶1.1 这个系统到底要解决什么问题整套系统最开始的需求其实很朴素给宠物建一份电子档案记录它每个阶段的体重、体长、健康状况、疫苗和喂养情况最终能自动生成成长曲线提醒我什么时候该驱虫、该打下一针疫苗。把需求拆开之后系统的功能边界就很清晰了不需要复杂的权限体系不需要多租户更不需要微服务一个轻量级后端加一个单页前端就完全够用。所谓宠物成长监管本质上就是围绕宠物档案-成长记录-健康提醒这三条线去做增删改查和可视化展示。很多初学者一上来就想堆功能我建议先控制住冲动把主流程跑通再谈扩展。1.2 Flask和Django我为什么选了前者这个问题我在项目初期也纠结过一阵。标题里虽然经常把Flask和Django放在一起搜但实际开发体验差别很大。Django的优势是全家桶自带Admin后台、ORM、迁移、表单、认证开箱即用。对于后台管理系统来说Django确实省事。但正因为自带的东西太多我这种从小项目出发的需求反而要被框架带着走改个表结构要过migration加个接口要走它的URLConf和View体系那种被框架安排得明明白白的感觉其实挺影响自由度的。Flask则完全是另一个路子它只提供最小内核路由和视图函数自己定义ORM、表单校验、登录认证这些都可以按需插入。对宠物成长监管系统这种接口相对简单的场景来说Flask的轻反而是最大优势。我只需要写一个app目录配上Blueprint组织模块剩下的事情自己掌握节奏。1.3 Vue在项目里承担的角色前端选择Vue的原因也很实际宠物成长数据需要频繁更新、筛选、可视化展示如果再用Flask渲染模板一套套传Jinja2数据页面一旦复杂起来DOM操作会变得非常痛苦。Vue的数据绑定和组件化正好解决这个问题。我特别看重的是Vue的响应式机制。宠物列表里某条记录的体重一改页面上的折线图、平均值数字、最新体态标签会自动联动刷新不需要手动去操作DOM节点。这一套在前端圈早就被说烂了但真正把Vue和Flask前后端分离配合起来做项目时你才会直观感受到开发效率的差距后端只输出JSON前端只关心数据状态联调时只要约定好接口格式就行。1.4 开发前需要备齐的锅碗瓢盆既然标题里带到了PyCharm我就把环境准备一并说清楚。这个项目的开发环境是Win11 PHPStorm的兄弟PyCharm ProfessionalPython用的3.10Flask用的2.3.x前端是Vue3 Vite。有一点值得提醒不要盲目追新版本Python 3.12刚出来时部分依赖库还没做好适配我在一个临时测试环境里就踩过兼容坑。在PyCharm里新建项目时我习惯用虚拟环境venv而不是用全局Python解释器。这样不同项目之间的依赖互相隔离后面换机器部署时只需要导出一份requirements.txt就能还原环境。Vue项目则要求本机有Node.js 18以上通过npm create vuelatest初始化再用npm安装axios、vue-router、element-plus和echarts这些依赖。依赖版本建议锁定不要在任何环境里随手安装最新版。后文我会专门讲这个坑。2. 先搞定数据模型宠物成长监管系统的地基设计2.1 六张核心表理清业务边界写代码之前先画数据表这一步比写任何接口都重要。我的设计里一共六张核心表用户表、宠物档案表、成长记录表、健康指标表、疫苗记录表、喂养计划表。表名职责关键字段owner养宠人账号id, username, password_hash, email, created_atpet_profile宠物基础档案id, owner_id, name, species, breed, gender, birthday, sterilized, avatar, created_atgrowth_record每次测量的成长数据id, pet_id, weight, body_length, chest_circumference, measured_at, notehealth_metric健康指标体温心率等id, pet_id, heart_rate, temperature, respiratory_rate, measured_atvaccine_record疫苗注射记录id, pet_id, vaccine_name, dose, vaccinated_at, hospital, next_vaccine_atfeeding_plan每日喂养计划与提醒id, pet_id, feed_time, food_name, amount_gram, remind_enabled表设计的原则是一张表只做一件事。比如健康指标和成长记录如果揉进一张表字段就会变得又长又稀疏查体重趋势时还得过滤掉大量体温数据查询效率很差。拆开后前端统计和图表渲染都直接走单表逻辑简单清晰。2.2 冗余字段的设计取舍这里我想专门说一个容易被新手忽略的细节成长记录表里的weight和measured_at字段看起来和pet_profile表里的字段没直接关系但我在设计时特意让growth_record冗余了measured_at的时间戳而不是依赖记录的创建时间。原因很简单宠物称重的时间一定是你手动录入的时间可能是在早上喂食前也可能是在晚上洗澡后。如果直接用记录的created_at那么历史数据的统计口径会被导入时间、修改时间干扰画出来的曲线会失真。成长监管系统最核心的价值就是时间序列上的变化所以被测时间理应是业务上的关键字段独立存储而不是拿后台自动生成的时间戳来代替。类似的取舍还有pet_profile表里的species和breed直接存字符串而不是存外键到品种字典。对于单机小系统来说字典表当然更规范但换来的是每次查询都多一次关联。我自己权衡了一下字符串可读性强、录入方便先不做那种过度设计。2.3 用SQLAlchemy定义模型的示例数据表确定之后代码层面的ORM模型就顺理成章了。我用的是Flask-SQLAlchemy为什么用它而不是直接裸写SQL因为ORM把建表、CRUD和关系映射统一在一起写起来像操作Python对象排查问题时也能通过db.session的日志看到底层SQL。from flask_sqlalchemy import SQLAlchemy from datetime import datetime db SQLAlchemy() class PetProfile(db.Model): __tablename__ pet_profile id db.Column(db.Integer, primary_keyTrue) owner_id db.Column(db.Integer, db.ForeignKey(owner.id), nullableFalse) name db.Column(db.String(32), nullableFalse) species db.Column(db.String(16), defaultcat) breed db.Column(db.String(32)) gender db.Column(db.String(8)) birthday db.Column(db.Date) sterilized db.Column(db.Boolean, defaultFalse) avatar db.Column(db.String(128)) created_at db.Column(db.DateTime, defaultdatetime.now) records db.relationship(GrowthRecord, backrefpet, lazydynamic) class GrowthRecord(db.Model): __tablename__ growth_record id db.Column(db.Integer, primary_keyTrue) pet_id db.Column(db.Integer, db.ForeignKey(pet_profile.id), nullableFalse) weight db.Column(db.Float, nullableFalse) body_length db.Column(db.Float) chest_circumference db.Column(db.Float) measured_at db.Column(db.DateTime, nullableFalse) note db.Column(db.Text) __table_args__ ( db.Index(idx_pet_measured, pet_id, measured_at), )细心的你可能注意到了我给growth_record加了联合索引idx_pet_measured。宠物数据一旦记录起来每次体检、每周称重都会新增一行一段时间后数据量就很可观。按pet_id和measured_at查趋势图是最常见的操作这个联合索引能让SQL走索引扫描查询性能提升非常明显。2.4 数据库迁移用Flask-Migrate管理表结构还有一个强烈建议从项目一开始就接入Flask-Migrate别等着表结构已经跑起来了再手动改库。我第一版就没上迁移后来加字段时直接在数据库里手动执行ALTER TABLE结果测试环境的库和开发环境的库字段对不上前端接口一会有一会没有排查起来非常折磨。接入其实就几行代码from flask_migrate import Migrate migrate Migrate(app, db)之后每次改模型只需要在PyCharm终端里执行flask db migrate -m add body_length to growth_record flask db upgrade这套流程把表结构变更变成了版本化的迁移文件团队协作或个人换设备时都能用同样的命令把库还原到一致的状态。别嫌麻烦这个习惯越早养成越受益。3. Flask后端API把每个功能点变成可以调用的接口3.1 用蓝图层级拆分业务模块后端我按业务模块拆成了三个Blueprintpet_bp管宠物档案record_bp管成长记录和健康指标reminder_bp管疫苗和喂养提醒。每个Blueprint对应一个Python文件视图函数里只写请求解析、参数校验和响应返回具体的数据组装放在service层。为什么要用Blueprint如果你把所有的app.route全写在一个文件里项目刚开始只有十几个接口还能忍一旦功能扩到三十个以上文件就会变成一团乱麻。Blueprint的意义在于给每个模块划清边界比如pet_bp定义url_prefix/api/pets那么pet_bp里所有路由都会自动挂在/api/pets下面路由命名清晰也不会和其他模块冲突。3.2 创建宠物档案和成长记录的核心接口后端API的核心逻辑并不神秘就是规范地处理请求、落库、返回结果。下面是我创建宠物和新增成长记录的两个核心接口。from flask import Blueprint, request, jsonify from app.models import db, PetProfile, GrowthRecord pet_bp Blueprint(pet, __name__, url_prefix/api/pets) pet_bp.route(, methods[POST]) def create_pet(): data request.get_json(silentTrue) or {} if not data.get(name): return jsonify(code400, message宠物名称不能为空) pet PetProfile( owner_iddata.get(owner_id, 1), # 当前版本先固定单用户 namedata[name], speciesdata.get(species, cat), breeddata.get(breed, ), genderdata.get(gender, ), birthdaydata.get(birthday), sterilizeddata.get(sterilized, False) ) db.session.add(pet) db.session.commit() return jsonify(code0, messageok, data{id: pet.id, name: pet.name}) record_bp Blueprint(record, __name__, url_prefix/api/records) record_bp.route(/pets/int:pet_id, methods[POST]) def add_growth_record(pet_id): data request.get_json(silentTrue) or {} weight data.get(weight) if not weight: return jsonify(code400, message体重不能为空) record GrowthRecord( pet_idpet_id, weightfloat(weight), body_lengthfloat(data.get(body_length, 0) or 0), chest_circumferencefloat(data.get(chest_circumference, 0) or 0), measured_atdatetime.strptime(data.get(measured_at), %Y-%m-%d %H:%M:%S), notedata.get(note, ) ) db.session.add(record) db.session.commit() return jsonify(code0, messageok, data{id: record.id})关于路由设计多说一句RESTful的风格是名词复数HTTP动词POST /api/pets代表创建宠物POST /api/records/pets/3代表给3号宠物新增记录。有些初学者习惯写POST /addPetRecord这种动词式路由也不能说就错但前后端联调时接口列表会非常杂乱还是建议一开始就按资源来组织。3.3 请求参数与统一响应格式联调阶段最多的问题出在参数解析上。Flask接收前端数据有多种方式常见的有request.argsURL查询参数、request.form表单、request.get_json()JSON体。我有一个调试接口时固定会用的套路在PyCharm里的断点模式下直接打印from flask import request data request.get_json(silentTrue) print(type(data), data)别小看这一行很多前端传了数据后端拿不到的问题一打印就真相大白有时候axios默认把对象序列化成了JSON后端却在用request.form取数据自然什么都拿不到。响应格式上我统一用{code: 0, message: ok, data: {...}}这套结构。前端axios拦截器统一判断code成功就取data失败就对message做错误提示。这样不管接口返回的是列表还是单条JSON前端只用写一套处理逻辑异常情况也有统一的出口。3.4 图片上传宠物头像的处理与静态文件坑宠物档案里需要上传头像本来以为是个小功能结果踩了不少坑这里直接分享我的最终方案。上传时前端用FormData提交文件后端用request.files接收保存到本地uploads目录并把可访问的URL存进数据库。import os from werkzeug.utils import secure_filename UPLOAD_FOLDER os.path.join(os.getcwd(), uploads) ALLOWED_EXTENSIONS {png, jpg, jpeg, gif} pet_bp.route(/int:pet_id/avatar, methods[POST]) def upload_avatar(pet_id): file request.files.get(avatar) if not file or file.filename : return jsonify(code400, message未接收到文件) filename secure_filename(file.filename) ext filename.rsplit(., 1)[1].lower() if ext not in ALLOWED_EXTENSIONS: return jsonify(code400, message不支持的图片格式) pet PetProfile.query.get_or_404(pet_id) upload_filename fpet_{pet_id}_{filename} os.makedirs(UPLOAD_FOLDER, exist_okTrue) file.save(os.path.join(UPLOAD_FOLDER, upload_filename)) pet.avatar f/uploads/{upload_filename} db.session.commit() return jsonify(code0, messageok, data{avatar_url: pet.avatar})要提供/uploads路径的文件访问不能只保存不服务。我定义了一个路由from flask import send_from_directory app.route(/uploads/path:filename) def uploaded_file(filename): return send_from_directory(UPLOAD_FOLDER, filename)最容易踩的坑有两个。第一保存目录如果不存在直接报错所以一定要os.makedirs(UPLOAD_FOLDER, exist_okTrue)。第二Windows开发环境和Linux服务器之间路径分隔符不一致这里用的是os.path.join跨平台就没问题。3.5 用Flask-SocketIO做后台数据主动推送宠物成长监管系统里有一个比较有进阶感的功能实时健康监控。传统做法是前端每隔几秒轮询接口能实现但很浪费资源。我在这套系统里接入了Flask-SocketIO让后端在有新健康指标时主动推给前端前端的监控面板就能实时跳动不用反复发HTTP请求。from flask_socketio import SocketIO, emit, join_room socketio SocketIO(app, cors_allowed_origins*) def push_health_data(pet_id): import random, time while True: time.sleep(5) socketio.emit(health_update, { pet_id: pet_id, heart_rate: random.randint(90, 120), temperature: round(random.uniform(38.0, 39.5), 1), recorded_at: datetime.now().strftime(%Y-%m-%d %H:%M:%S) }, roompet_ str(pet_id)) socketio.on(subscribe_pet) def on_subscribe(data): pet_id data.get(pet_id) join_room(pet_ str(pet_id)) socketio.start_background_task(push_health_data, pet_id)后端通过room把某个宠物的数据推送给所有订阅了这个宠物房间的客户端。前端用socket.io-client监听health_update事件一旦收到数据就更新页面上最新的体温、心率数字。这个机制给未来的IoT接入也留了位置智能项圈采集到的数据可以直接推给后端再由后端广播给前端页面。4. Vue前端搭出看得见的监管面板4.1 初始化Vue项目与依赖选择前端部分我用Vite创建Vue3项目因为Vite启动速度快开发体验比webpack时代舒服太多。核心依赖按功能选axios发送HTTP请求vue-router页面路由跳转element-plusUI组件库表格、表单、对话框直接用现成的echarts画宠物成长曲线图别一股脑装一堆UI库和插件够用就行。我一开始装了十几个npm包最后用得上的不到一半还拖慢了构建速度。4.2 axios封装让每个接口都能被稳定调用axios不封装直接用也不是不行但接口一多就会重复一堆URL拼接和错误处理代码。我习惯在src/api/index.js里做一层统一封装import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.response.use( response { if (response.data.code 0) { return response.data.data } return Promise.reject(new Error(response.data.message)) }, error { console.error(接口请求异常, error.message) return Promise.reject(error) } ) export default request这样每个具体的接口函数只需要关心业务数据不用重复处理code判断。比如宠物详情的接口就写成export function fetchPetDetail(id) { return request.get(/pets/${id}) }4.3 核心页面组件宠物列表、详情、成长曲线页面结构我拆成了三个核心组件宠物列表页、宠物详情页、成长曲线卡片。宠物列表页很简单一个表格加一个新增宠物按钮点击打开dialog表单提交后重新拉取列表。宠物详情页是系统信息量最集中的地方上部分是宠物基本信息卡片头像、品种、生日、绝育状态中间部分是最近一次健康指标下部分是成长记录表和对应echarts折线图。这里我特别推荐把成长曲线单独抽成一个组件只接收records数组作为props。这样宠物详情页任何操作后只要更新records数组折线图会自动重新渲染。echarts画体重曲线很简单把records按时间排个序x轴是measured_aty轴是weightlines平滑一点一张趋势图就出来了。这个图是整个监管系统最有监管感的功能数据积累起来之后非常有价值。4.4 路由传参从列表页跳详情页的正确姿势列表页跳详情页很多人第一反应是query参数比如/pet/detail?id3。但Vue Router更推荐用动态路由参数。const routes [ { path: /, component: PetList }, { path: /pet/:id, component: PetDetail } ]跳转时用router.push(/pet/${row.id})详情页里用useRoute()读取import { useRoute } from vue-router const route useRoute() const petId route.params.id用动态路由的好处是URL本身就有语义前端埋点、分享、刷新都不会丢参数。如果传大量复杂对象比如整个row对象刷新页面后数据就丢了这是很多新手踩过的大坑。4.5 接上WebSocket让监控面板动起来Vue端接入socket.io-client监听后端推送的健康数据import { io } from socket.io-client const socket io(http://127.0.0.1:5000) socket.on(connect, () { socket.emit(subscribe_pet, { pet_id: currentPetId.value }) }) socket.on(health_update, data { latestHealth.value data })页面上体温、心率区域的数字会每5秒跳动一次因为后端会持续广播这个实时效果对演示项目来说非常加分。不过要注意socket.io默认会建立一条长连接部署时服务端要支持WebSocket协议nginx代理需要设置Upgrade头这个后面部署章节再提。5. PyCharm联调阶段我踩过的那些真实坑5.1 虚拟环境混乱换个机器就报错写代码时依赖是装好一个用一个问题不大。真正崩溃是在我换到另一台电脑继续开发时一跑项目直接ModuleNotFoundError: No module named flask_cors。原因很简单我虽然建了venv但依赖一直靠缺什么pip装什么没有形成一份完整的依赖清单。后来我把PyCharm终端调出来执行了一句pip freeze requirements.txt换机器时直接运行pip install -r requirements.txt问题就再也没出现过。有一个细节venv目录不要提交到Git里否则换机器会直接把本地环境覆盖掉到时候哭都来不及。在项目根目录用.gitignore忽略venv、node_modules、dist、uploads这些目录。5.2 request.json和request.form是两码事这个坑应该能让不少Flask新手当场抓狂。前端明明在Postman或axios里传了JSON数据后端接口却一直报参数为空。我一开始也这么干过前端用的是axios默认的application/json请求体后端却用request.form去读结果拿到的永远是空。Flask框架里request.form只解析multipart/form-data格式而request.get_json()才解析JSON字符串。正确判断方式是先看请求头的Content-Type。前后端联调时一般前端传对象就默认是JSON后端统一用data request.get_json(silentTrue) or {}silentTrue的优点在于即使解析失败也不会抛异常返回None再配合or {}转成空字典接口就不会直接500。找问题的时候在PyCharm里打上断点看data的类型和值一眼就知道前端到底传了什么。5.3 前端图片不显示的完整排查链路宠物头像上传成功了数据库里也有路径但前端img标签一直显示不出来最终排查链路大概是这样的先看返回的avatar_url是什么样。我在后端的返回值是/uploads/pet_1_xxx.jpg前端直接拼在域名后面访问。结果浏览器控制台报404说明Flask根本没有路由处理这个路径我一开始忘了定义/uploads/path:filename那个send_from_directory方法补上之后404消失。再看MIME类型。Flask的send_from_directory会自动根据文件扩展名判断Content-Typejpg显示正常但如果保存文件名时把扩展名搞丢了浏览器可能当成application/octet-stream来下载而不是直接显示。所以我用了secure_filename之后又主动用old_name.rsplit(., 1)[-1]把扩展名抠出来拼上。最后一个是浏览器缓存问题。同一张图片改了内容但浏览器缓存了旧资源看起来就像没更新。解决办法是给图片URL加个时间戳参数avatarUrl.value pet.avatar ?t Date.now()这三个问题按顺序排查基本能覆盖日常开发中八九成的图片不显示场景。5.4 前后端时间不一致导致成长记录错位Flask里我一开始用datetime.now()记录measured_at的默认值后来部署到服务器上才发现服务器时区可能和本地不同记录时间对不上用户的实际操作时间。这里建议前端把时间统一转成ISO 8601字符串传给后端比如2024-06-01T08:30:00后端解析后存成datetime。展示的时候前端再用new Date(value)本地化显示这样用户不管在哪个时区看到的都是和他本地一致的时间。数据库层面我习惯用UTC时间存储业务以外的时间字段比如created_at、updated_at。这两个字段纯粹是后台审计用统一UTC不存在歧义。用户真正关心的measured_at、vaccinated_at这类时间则必须按业务本地时间处理不能一概而论。5.5 刷新页面404Vue路由模式选对了没这个坑大概率会让本地开发好好的、一旦部署就崩的项目怀疑人生。问题出在Vue Router默认的history模式路由跳转是前端控制的没问题但用户手动刷新页面时浏览器会按当前URL向服务器发起请求比如访问/pet/3服务器没有对应的静态文件或后端路由就返回404了。开发环境下Vite会给所有路由返回index.html所以本地从来不会发现这个问题。部署后由nginx托管时需要在nginx配置里加一个兜底规则location / { root /var/www/vue_dist; try_files $uri $uri/ /index.html; }这行的意思是请求路径能匹配到静态文件就返回文件匹配不到就一律返回index.html让Vue Router接管路由解析。如果你不想在服务器上配置这一层也可以直接把Vue Router切换为createWebHashHistoryURL里会多个#号刷新就不会404。听我一句劝既然都做前后端分离了还是用history模式加nginx配置别用hash模式掩饰问题。6. 从本机到服务器部署上线与后续扩展方向6.1 gunicornnginx主流部署Windows上另有替代Flask自带的app.run()千万不能用于生产环境它只是一个面向开发的WSGI服务器并发能力很弱。常规做法是在Linux服务器上用gunicorn启动Flask应用pip install gunicorn gunicorn -w 3 -b 0.0.0.0:8000 wsgi:app-w 3表示启动3个worker进程每个进程都是独立的Python解释器多个进程扛住并发请求。需要注意的是项目入口文件必须暴露名为app的Flask实例比如wsgi.py里写from app import create_app app create_app()如果你和我一样临时在Windows服务器上做内网演示gunicorn是装不上的。Windows平台建议用waitress作为替代用法也很简单pip install waitress waitress-serve --listen0.0.0.0:8000 wsgi:appnginx层主要负责两件事静态文件托管和反向代理。Vue构建后的dist目录直接配到nginx的root下axios请求的/api路径反向代理到后端端口location /api { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }如果项目用了WebSocket长连接nginx的这部分额外配置不能少location /socket.io { proxy_pass http://127.0.0.1:8000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; }少了Upgrade头Socket连接会被nginx静默切掉前端表现为连上就断开或根本连不上这时候你查后端日志大概率看不到任何报错会特别迷茫。6.2 可以继续做下去的扩展方向这套系统的核心骨架已经完整后续想升级基本都是在现有表结构上做文章。一个方向是IoT接入。给宠物戴上智能项圈项圈采集的体温、心率、运动步数通过MQTT协议上传到服务器后端收到后自动写入health_metric表前端监控面板就变成了真正的实时监管。我在Flask-SocketIO那一节已经留好了socketio.emit的位置硬件数据接入只需要在订阅函数里替换掉模拟数据来源剩下不用改。另一个方向是AI化的体态评估。现在长得挺圆润、挺标准这类判断全靠肉眼可以上传宠物照片调用训练好的图像分类模型估算体况评分BCS自动写入健康数据。这个功能对前端来说只是增加一个上传组件后端加一个调用模型的service整个架构完全兼容。还有一个很实用的多人共享功能现在的owner表是单用户设计扩展成家庭模式后可以让家人一起记录、查看同一只宠物的成长数据尤其适合家里有多个养宠成员的情况。6.3 一点个人体会做完这套宠物成长监管系统我最大的感受是一个项目能不能做下去往往不取决于技术选型多前沿而是数据模型够不够稳、接口约定够不够清晰、边界划分够不够明确。Flask给了你自由度Vue给了你交互空间PyCharm给了你调试效率真正的瓶颈永远是你在动手前有没有把业务想明白。如果你也正在做类似的项目我的建议只有一条先写数据表再谈功能。当你把宠物、成长记录、健康指标这些概念变成一张张表的时候这个系统的大脑就已经成型了后面写接口和页面都是往这棵树上添枝叶而已。