diff --git a/AGENTS.md b/AGENTS.md
deleted file mode 100644
index 789f6a7..0000000
--- a/AGENTS.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# Repository Guidelines
-
-## Project Structure & Module Organization
-- `backend/` is a Spring Boot 2.7 (Java 17) service with MyBatis-Plus and JWT security.
- - Main code: `backend/src/main/java/com/gpf/pethospital`
- - Config: `backend/src/main/resources/application.yml` and `application-dev.yml`
-- `frontend/` is a Vue 3 + Vite app with Pinia and TDesign.
- - Source: `frontend/src/` (pages, router, store, layouts, styles)
- - Static assets: `frontend/src/assets/`
-- `docs/` and `*.drawio` contain documentation and UML/ER diagrams.
-- `frp/` and `start_frp.sh` include FRP configuration/scripts.
-
-## Build, Test, and Development Commands
-Backend (from `backend/`):
-- `mvn spring-boot:run` — run the API locally.
-- `mvn clean package` — build a runnable jar.
-- `mvn test` — run Spring Boot tests (if present).
-
-Frontend (from `frontend/`):
-- `npm install` — install dependencies.
-- `npm run dev` — start Vite dev server.
-- `npm run build` — production build.
-- `npm run preview` — preview the production build.
-
-## Coding Style & Naming Conventions
-- Java: 4-space indentation, standard Spring Boot conventions, packages under `com.gpf.pethospital`.
-- Vue/TypeScript: ES module syntax, semicolons used; follow existing file structure.
-- Use descriptive, domain-specific names (e.g., `AppointmentController`, `appointmentService`).
-
-## Testing Guidelines
-- No dedicated test directories are present yet.
-- Backend tests should go in `backend/src/test/java` using Spring Boot Test.
-- Frontend has no test runner configured; if adding, include a script in `frontend/package.json`.
-
-## Commit & Pull Request Guidelines
-- Current commit history uses short Chinese descriptions like “添加…” and “将…更改为…”.
-- Keep messages short, imperative, and meaningful; avoid placeholder commits like “1”.
-- PRs should include: a clear summary, testing performed (or “not run”), and screenshots for UI changes.
-
-## Configuration & Security Notes
-- `application-dev.yml` contains local MySQL defaults (user `root`, password `password`).
- Update credentials via environment or local overrides; do not commit real secrets.
-- JWT secrets are currently hardcoded in config; rotate for real deployments.
diff --git a/format_thesis_docx.py b/format_thesis_docx.py
new file mode 100644
index 0000000..7f43dec
--- /dev/null
+++ b/format_thesis_docx.py
@@ -0,0 +1,178 @@
+from docx import Document
+from docx.enum.text import WD_ALIGN_PARAGRAPH
+from docx.oxml import OxmlElement
+from docx.oxml.ns import qn
+from docx.shared import Pt, RGBColor
+
+
+SRC = r"D:\bs\gpf_pet_hospital\爱维宠物医院管理系统毕业论文-2026版.docx"
+DST = r"D:\bs\gpf_pet_hospital\爱维宠物医院管理系统毕业论文-2026版-排版.docx"
+
+
+def set_style_font(
+ style,
+ east_asia_font: str,
+ size_pt: float,
+ bold: bool | None = None,
+ west_font: str = "Times New Roman",
+):
+ font = style.font
+ font.name = west_font
+ font.size = Pt(size_pt)
+ if bold is not None:
+ font.bold = bold
+ font.color.rgb = RGBColor(0, 0, 0)
+ rfonts = style.element.get_or_add_rPr().get_or_add_rFonts()
+ rfonts.set(qn("w:ascii"), west_font)
+ rfonts.set(qn("w:hAnsi"), west_font)
+ rfonts.set(qn("w:eastAsia"), east_asia_font)
+
+
+def set_runs_font(
+ paragraph,
+ east_asia_font: str,
+ size_pt: float,
+ bold: bool | None = None,
+ west_font: str = "Times New Roman",
+):
+ for run in paragraph.runs:
+ run.font.name = west_font
+ run.font.size = Pt(size_pt)
+ if bold is not None:
+ run.font.bold = bold
+ run.font.color.rgb = RGBColor(0, 0, 0)
+ rpr = run._element.get_or_add_rPr()
+ rfonts = rpr.get_or_add_rFonts()
+ rfonts.set(qn("w:ascii"), west_font)
+ rfonts.set(qn("w:hAnsi"), west_font)
+ rfonts.set(qn("w:eastAsia"), east_asia_font)
+
+
+def set_runs_common(paragraph, italic: bool | None = None, color_black: bool = True):
+ for run in paragraph.runs:
+ if italic is not None:
+ run.font.italic = italic
+ if color_black:
+ run.font.color.rgb = RGBColor(0, 0, 0)
+
+
+def is_numbered_paragraph(paragraph) -> bool:
+ ppr = paragraph._p.pPr
+ if ppr is None:
+ return False
+ return ppr.numPr is not None
+
+
+def set_table_all_borders_black(table):
+ for row in table.rows:
+ for cell in row.cells:
+ tc = cell._tc
+ tc_pr = tc.get_or_add_tcPr()
+ tc_borders = tc_pr.find(qn("w:tcBorders"))
+ if tc_borders is None:
+ tc_borders = OxmlElement("w:tcBorders")
+ tc_pr.append(tc_borders)
+ for edge in ("top", "left", "bottom", "right", "insideH", "insideV"):
+ edge_tag = qn(f"w:{edge}")
+ elem = tc_borders.find(edge_tag)
+ if elem is None:
+ elem = OxmlElement(f"w:{edge}")
+ tc_borders.append(elem)
+ elem.set(qn("w:val"), "single")
+ elem.set(qn("w:sz"), "8")
+ elem.set(qn("w:color"), "000000")
+ elem.set(qn("w:space"), "0")
+
+
+def iter_table_paragraphs(table):
+ for row in table.rows:
+ for cell in row.cells:
+ for p in cell.paragraphs:
+ yield p
+ for t in cell.tables:
+ yield from iter_table_paragraphs(t)
+
+
+def format_paragraph(p):
+ style_name = p.style.name if p.style is not None else ""
+ if style_name == "Heading 1":
+ apply_para_format(p, 1.5, 0, WD_ALIGN_PARAGRAPH.CENTER)
+ set_runs_font(p, "黑体", 22, True)
+ elif style_name == "Heading 2":
+ apply_para_format(p, 1.5, 32)
+ set_runs_font(p, "黑体", 16, True)
+ elif style_name == "Heading 3":
+ apply_para_format(p, 1.5, 28)
+ set_runs_font(p, "宋体", 14, True)
+ elif style_name == "Heading 4":
+ apply_para_format(p, 1.5, 24)
+ set_runs_font(p, "宋体", 12, True)
+ set_runs_common(p, italic=False, color_black=True)
+ elif is_numbered_paragraph(p) or style_name.startswith("List Number"):
+ p.paragraph_format.line_spacing = 1.5
+ set_runs_font(p, "宋体", 12)
+ set_runs_common(p, color_black=True)
+ else:
+ apply_para_format(p, 1.5, 24)
+ set_runs_font(p, "宋体", 12)
+ set_runs_common(p, color_black=True)
+
+
+def apply_para_format(paragraph, line_spacing: float, first_line_pt: float | None = None, align=None):
+ fmt = paragraph.paragraph_format
+ fmt.line_spacing = line_spacing
+ if first_line_pt is not None:
+ fmt.first_line_indent = Pt(first_line_pt)
+ if align is not None:
+ paragraph.alignment = align
+
+
+def main():
+ doc = Document(SRC)
+
+ normal = doc.styles["Normal"]
+ h1 = doc.styles["Heading 1"]
+ h2 = doc.styles["Heading 2"]
+ h3 = doc.styles["Heading 3"]
+ h4 = doc.styles["Heading 4"]
+
+ # 正文：宋体小四，首行缩进2字符（约24pt），1.5倍行距
+ set_style_font(normal, "宋体", 12)
+ normal.paragraph_format.line_spacing = 1.5
+ normal.paragraph_format.first_line_indent = Pt(24)
+
+ # 标题1：黑体二号，加粗，居中，1.5倍行距
+ set_style_font(h1, "黑体", 22, True)
+ h1.paragraph_format.line_spacing = 1.5
+ h1.paragraph_format.first_line_indent = Pt(0)
+
+ # 标题2：黑体三号，加粗，首行缩进2字符，1.5倍行距
+ set_style_font(h2, "黑体", 16, True)
+ h2.paragraph_format.line_spacing = 1.5
+ h2.paragraph_format.first_line_indent = Pt(32)
+
+ # 标题3：宋体四号，加粗，首行缩进2字符，1.5倍行距
+ set_style_font(h3, "宋体", 14, True)
+ h3.paragraph_format.line_spacing = 1.5
+ h3.paragraph_format.first_line_indent = Pt(28)
+
+ # 标题4：加粗，取消斜体，黑色，1.5倍行距
+ set_style_font(h4, "宋体", 12, True)
+ h4.font.italic = False
+ h4.paragraph_format.line_spacing = 1.5
+ h4.paragraph_format.first_line_indent = Pt(24)
+
+ for p in doc.paragraphs:
+ format_paragraph(p)
+
+ for t in doc.tables:
+ set_table_all_borders_black(t)
+ for p in iter_table_paragraphs(t):
+ format_paragraph(p)
+
+ doc.save(DST)
+ print(DST)
+
+
+if __name__ == "__main__":
+ main()
diff --git a/frp/LICENSE b/frp/LICENSE
deleted file mode 100644
index 8f71f43..0000000
--- a/frp/LICENSE
+++ /dev/null
@@ -1,202 +0,0 @@
- Apache License
- Version 2.0, January 2004
- http://www.apache.org/licenses/
-
- TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
- 1. Definitions.
-
- "License" shall mean the terms and conditions for use, reproduction,
- and distribution as defined by Sections 1 through 9 of this document.
-
- "Licensor" shall mean the copyright owner or entity authorized by
- the copyright owner that is granting the License.
-
- "Legal Entity" shall mean the union of the acting entity and all
- other entities that control, are controlled by, or are under common
- control with that entity. For the purposes of this definition,
- "control" means (i) the power, direct or indirect, to cause the
- direction or management of such entity, whether by contract or
- otherwise, or (ii) ownership of fifty percent (50%) or more of the
- outstanding shares, or (iii) beneficial ownership of such entity.
-
- "You" (or "Your") shall mean an individual or Legal Entity
- exercising permissions granted by this License.
-
- "Source" form shall mean the preferred form for making modifications,
- including but not limited to software source code, documentation
- source, and configuration files.
-
- "Object" form shall mean any form resulting from mechanical
- transformation or translation of a Source form, including but
- not limited to compiled object code, generated documentation,
- and conversions to other media types.
-
- "Work" shall mean the work of authorship, whether in Source or
- Object form, made available under the License, as indicated by a
- copyright notice that is included in or attached to the work
- (an example is provided in the Appendix below).
-
- "Derivative Works" shall mean any work, whether in Source or Object
- form, that is based on (or derived from) the Work and for which the
- editorial revisions, annotations, elaborations, or other modifications
- represent, as a whole, an original work of authorship. For the purposes
- of this License, Derivative Works shall not include works that remain
- separable from, or merely link (or bind by name) to the interfaces of,
- the Work and Derivative Works thereof.
-
- "Contribution" shall mean any work of authorship, including
- the original version of the Work and any modifications or additions
- to that Work or Derivative Works thereof, that is intentionally
- submitted to Licensor for inclusion in the Work by the copyright owner
- or by an individual or Legal Entity authorized to submit on behalf of
- the copyright owner. For the purposes of this definition, "submitted"
- means any form of electronic, verbal, or written communication sent
- to the Licensor or its representatives, including but not limited to
- communication on electronic mailing lists, source code control systems,
- and issue tracking systems that are managed by, or on behalf of, the
- Licensor for the purpose of discussing and improving the Work, but
- excluding communication that is conspicuously marked or otherwise
- designated in writing by the copyright owner as "Not a Contribution."
-
- "Contributor" shall mean Licensor and any individual or Legal Entity
- on behalf of whom a Contribution has been received by Licensor and
- subsequently incorporated within the Work.
-
- 2. Grant of Copyright License. Subject to the terms and conditions of
- this License, each Contributor hereby grants to You a perpetual,
- worldwide, non-exclusive, no-charge, royalty-free, irrevocable
- copyright license to reproduce, prepare Derivative Works of,
- publicly display, publicly perform, sublicense, and distribute the
- Work and such Derivative Works in Source or Object form.
-
- 3. Grant of Patent License. Subject to the terms and conditions of
- this License, each Contributor hereby grants to You a perpetual,
- worldwide, non-exclusive, no-charge, royalty-free, irrevocable
- (except as stated in this section) patent license to make, have made,
- use, offer to sell, sell, import, and otherwise transfer the Work,
- where such license applies only to those patent claims licensable
- by such Contributor that are necessarily infringed by their
- Contribution(s) alone or by combination of their Contribution(s)
- with the Work to which such Contribution(s) was submitted. If You
- institute patent litigation against any entity (including a
- cross-claim or counterclaim in a lawsuit) alleging that the Work
- or a Contribution incorporated within the Work constitutes direct
- or contributory patent infringement, then any patent licenses
- granted to You under this License for that Work shall terminate
- as of the date such litigation is filed.
-
- 4. Redistribution. You may reproduce and distribute copies of the
- Work or Derivative Works thereof in any medium, with or without
- modifications, and in Source or Object form, provided that You
- meet the following conditions:
-
- (a) You must give any other recipients of the Work or
- Derivative Works a copy of this License; and
-
- (b) You must cause any modified files to carry prominent notices
- stating that You changed the files; and
-
- (c) You must retain, in the Source form of any Derivative Works
- that You distribute, all copyright, patent, trademark, and
- attribution notices from the Source form of the Work,
- excluding those notices that do not pertain to any part of
- the Derivative Works; and
-
- (d) If the Work includes a "NOTICE" text file as part of its
- distribution, then any Derivative Works that You distribute must
- include a readable copy of the attribution notices contained
- within such NOTICE file, excluding those notices that do not
- pertain to any part of the Derivative Works, in at least one
- of the following places: within a NOTICE text file distributed
- as part of the Derivative Works; within the Source form or
- documentation, if provided along with the Derivative Works; or,
- within a display generated by the Derivative Works, if and
- wherever such third-party notices normally appear. The contents
- of the NOTICE file are for informational purposes only and
- do not modify the License. You may add Your own attribution
- notices within Derivative Works that You distribute, alongside
- or as an addendum to the NOTICE text from the Work, provided
- that such additional attribution notices cannot be construed
- as modifying the License.
-
- You may add Your own copyright statement to Your modifications and
- may provide additional or different license terms and conditions
- for use, reproduction, or distribution of Your modifications, or
- for any such Derivative Works as a whole, provided Your use,
- reproduction, and distribution of the Work otherwise complies with
- the conditions stated in this License.
-
- 5. Submission of Contributions. Unless You explicitly state otherwise,
- any Contribution intentionally submitted for inclusion in the Work
- by You to the Licensor shall be under the terms and conditions of
- this License, without any additional terms or conditions.
- Notwithstanding the above, nothing herein shall supersede or modify
- the terms of any separate license agreement you may have executed
- with Licensor regarding such Contributions.
-
- 6. Trademarks. This License does not grant permission to use the trade
- names, trademarks, service marks, or product names of the Licensor,
- except as required for reasonable and customary use in describing the
- origin of the Work and reproducing the content of the NOTICE file.
-
- 7. Disclaimer of Warranty. Unless required by applicable law or
- agreed to in writing, Licensor provides the Work (and each
- Contributor provides its Contributions) on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
- implied, including, without limitation, any warranties or conditions
- of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
- PARTICULAR PURPOSE. You are solely responsible for determining the
- appropriateness of using or redistributing the Work and assume any
- risks associated with Your exercise of permissions under this License.
-
- 8. Limitation of Liability. In no event and under no legal theory,
- whether in tort (including negligence), contract, or otherwise,
- unless required by applicable law (such as deliberate and grossly
- negligent acts) or agreed to in writing, shall any Contributor be
- liable to You for damages, including any direct, indirect, special,
- incidental, or consequential damages of any character arising as a
- result of this License or out of the use or inability to use the
- Work (including but not limited to damages for loss of goodwill,
- work stoppage, computer failure or malfunction, or any and all
- other commercial damages or losses), even if such Contributor
- has been advised of the possibility of such damages.
-
- 9. Accepting Warranty or Additional Liability. While redistributing
- the Work or Derivative Works thereof, You may choose to offer,
- and charge a fee for, acceptance of support, warranty, indemnity,
- or other liability obligations and/or rights consistent with this
- License. However, in accepting such obligations, You may act only
- on Your own behalf and on Your sole responsibility, not on behalf
- of any other Contributor, and only if You agree to indemnify,
- defend, and hold each Contributor harmless for any liability
- incurred by, or claims asserted against, such Contributor by reason
- of your accepting any such warranty or additional liability.
-
- END OF TERMS AND CONDITIONS
-
- APPENDIX: How to apply the Apache License to your work.
-
- To apply the Apache License to your work, attach the following
- boilerplate notice, with the fields enclosed by brackets "{}"
- replaced with your own identifying information. (Don't include
- the brackets!) The text should be enclosed in the appropriate
- comment syntax for the file format. We also recommend that a
- file or class name and description of purpose be included on the
- same "printed page" as the copyright notice for easier
- identification within third-party archives.
-
- Copyright {yyyy} {name of copyright owner}
-
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
diff --git a/frp/README.md b/frp/README.md
deleted file mode 100644
index 5f4e95c..0000000
--- a/frp/README.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# FRP 内网穿透工具
-
-## 文件说明
-
-- `frpc`: FRP 客户端可执行文件 (Linux AMD64)
-- `frps`: FRP 服务器端可执行文件 (Linux AMD64)
-- `frpc.ini`: 客户端配置文件模板
-- `frpc.toml`: 客户端配置文件示例 (TOML格式)
-- `frps.toml`: 服务器端配置文件示例 (TOML格式)
-- `LICENSE`: 许可证文件
-
-## 版本信息
-- FRP Version: 0.66.0
-- 架构: Linux AMD64
-
-## 配置说明
-
-### 客户端配置 (frpc.ini)
-这是一个用于宠物医院管理系统的典型配置：
-
-```ini
-[common]
-server_addr = your_server_ip_or_domain
-server_port = 7000
-token = your_token_here
-
-[web_frontend]
-type = http
-local_port = 5173
-custom_domains = hospital.yourdomain.com
-
-[web_backend]
-type = tcp
-local_port = 8081
-remote_port = 8081
-```
-
-## 启动服务
-
-### 启动客户端
-```bash
-./frpc -c frpc.ini
-```
-
-### 启动服务器端 (在公网服务器)
-```bash
-./frps -c frps.ini
-```
-
-## 用于宠物医院管理系统的典型配置
-
-请参考项目根目录下的 `frpc.ini` 配置文件，该文件已为宠物医院管理系统配置了适当的端口转发规则。
\ No newline at end of file
diff --git a/frp/frpc.ini b/frp/frpc.ini
deleted file mode 100644
index 1e9dfe7..0000000
--- a/frp/frpc.ini
+++ /dev/null
@@ -1,35 +0,0 @@
-# FRP 客户端配置文件 - 宠物医院管理系统
-# 请根据实际情况修改服务器地址和端口
-
-[common]
-# FRP 服务器地址 (公网服务器IP或域名)
-server_addr = your_server_ip_or_domain
-# FRP 服务器端口
-server_port = 7000
-# 通信密钥 (需与服务器端保持一致)
-token = your_token_here
-
-# 前端服务穿透 - Vue开发服务器
-[web_frontend]
-type = http
-local_port = 5173
-custom_domains = hospital.yourdomain.com
-# 替换为实际的域名
-
-# 后端服务穿透 - Spring Boot应用
-[web_backend]
-type = tcp
-local_port = 8081
-remote_port = 8081
-
-# 如果需要HTTPS支持
-[web_frontend_https]
-type = https
-local_port = 5173
-custom_domains = hospital.yourdomain.com
-
-# 管理面板 (如果需要远程管理)
-[dashboard]
-type = tcp
-local_port = 7500
-remote_port = 7500
\ No newline at end of file
diff --git a/frp/frpc.toml b/frp/frpc.toml
deleted file mode 100644
index 6438f04..0000000
--- a/frp/frpc.toml
+++ /dev/null
@@ -1,9 +0,0 @@
-serverAddr = "127.0.0.1"
-serverPort = 7000
-
-[[proxies]]
-name = "test-tcp"
-type = "tcp"
-localIP = "127.0.0.1"
-localPort = 22
-remotePort = 6000
diff --git a/frp/frps.toml b/frp/frps.toml
deleted file mode 100644
index 28e6d96..0000000
--- a/frp/frps.toml
+++ /dev/null
@@ -1 +0,0 @@
-bindPort = 7000
diff --git a/frp/run_frpc.sh b/frp/run_frpc.sh
deleted file mode 100644
index 0b8d8cc..0000000
--- a/frp/run_frpc.sh
+++ /dev/null
@@ -1,18 +0,0 @@
-#!/bin/bash
-
-# 启动FRP客户端 - 宠物医院管理系统
-
-echo "启动FRP客户端..."
-
-# 检查配置文件是否存在
-if [ ! -f "frpc.ini" ]; then
- echo "错误: 未找到配置文件 frpc.ini"
- echo "请先创建配置文件或复制示例文件"
- exit 1
-fi
-
-# 启动frpc
-echo "正在启动FRP客户端..."
-./frpc -c frpc.ini
-
-echo "FRP客户端已退出"
\ No newline at end of file
diff --git a/frp_setup_guide.md b/frp_setup_guide.md
deleted file mode 100644
index 5f0eb68..0000000
--- a/frp_setup_guide.md
+++ /dev/null
@@ -1,144 +0,0 @@
-# FRP 内网穿透工具安装指南
-
-## 当前状态
-- 已安装: frps (服务器端) - 位于 `/mnt/d/bs/gpf_pet_hospital/frp/frps`
-- 已安装: frpc (客户端) - 位于 `/mnt/d/bs/gpf_pet_hospital/frp/frpc`
-- 版本: FRP 0.66.0 for Linux AMD64
-
-## 方法一：手动下载 (推荐)
-
-### 1. 下载最新版本的FRP
-```bash
-# 进入项目目录
-cd /mnt/d/bs/gpf_pet_hospital
-
-# 下载最新版本的FRP
-wget https://github.com/fatedier/frp/releases/download/v0.66.0/frp_0.66.0_linux_amd64.tar.gz
-
-# 解压
-tar -xzf frp_0.66.0_linux_amd64.tar.gz
-
-# 将frpc移动到frp目录
-mv frp_0.66.0_linux_amd64/frpc frp/
-
-# 清理
-rm -rf frp_0.66.0_linux_amd64 frp_0.66.0_linux_amd64.tar.gz
-```
-
-### 2. 配置FRPC
-创建配置文件 `/mnt/d/bs/gpf_pet_hospital/frp/frpc.ini`:
-
-```ini
-[common]
-server_addr = 你的公网IP或域名
-server_port = 7000
-
-[web]
-type = http
-local_port = 5173
-custom_domains = your-domain.com
-
-[backend]
-type = tcp
-local_port = 8081
-remote_port = 8081
-```
-
-## 方法二：使用Docker (如果可用)
-
-```bash
-# 启动FRPS服务器
-docker run -d --name frps \
- -p 7000:7000 \
- -p 7500:7500 \
- -p 8080:80 \
- --restart=always \
- snowdreamtech/frps:0.50.0
-
-# 启动FRPC客户端
-docker run -d --name frpc \
- --restart=always \
- -v /mnt/d/bs/gpf_pet_hospital/frp/frpc.ini:/etc/frp/frpc.ini \
- snowdreamtech/frpc:0.50.0
-```
-
-## 方法三：编译安装 (如果有Go环境)
-
-```bash
-# 安装Go (如果未安装)
-# Ubuntu/Debian: sudo apt-get install golang-go
-
-# 克隆仓库
-git clone https://github.com/fatedier/frp.git
-cd frp
-git checkout v0.66.0
-
-# 编译
-make frpc
-
-# 复制到目标位置
-cp bin/frpc /mnt/d/bs/gpf_pet_hospital/frp/
-```
-
-## 用于宠物医院管理系统的典型配置
-
-### FRPS 服务器配置 (frps.ini)
-```ini
-[common]
-bind_port = 7000
-dashboard_port = 7500
-dashboard_user = admin
-dashboard_pwd = admin
-vhost_http_port = 80
-vhost_https_port = 443
-token = your_token_here
-```
-
-### FRPC 客户端配置 (frpc.ini)
-```ini
-[common]
-server_addr = 你的公网服务器IP
-server_port = 7000
-token = your_token_here
-
-[pet-hospital-frontend]
-type = http
-local_port = 5173
-custom_domains = hospital.yourdomain.com
-
-[pet-hospital-backend]
-type = tcp
-local_port = 8081
-remote_port = 8081
-
-[pet-hospital-admin]
-type = http
-local_port = 5173
-custom_domains = admin.yourdomain.com
-```
-
-## 启动服务
-
-### 启动FRPS服务器 (在公网服务器)
-```bash
-cd /mnt/d/bs/gpf_pet_hospital/frp
-./frps -c frps.ini
-```
-
-### 启动FRPC客户端 (在本地机器)
-```bash
-cd /mnt/d/bs/gpf_pet_hospital/frp
-./frpc -c frpc.ini
-```
-
-## 注意事项
-1. 确保防火墙开放相应端口 (7000, 80, 443等)
-2. 在生产环境中使用强密码和密钥
-3. 定期更新FRP版本以获得安全补丁
-4. 监控FRP服务的运行状态
-
-## 故障排除
-- 检查网络连接
-- 确认端口未被占用
-- 查看FRP日志文件
-- 验证配置文件语法
\ No newline at end of file
diff --git a/simple_er_diagram.txt b/simple_er_diagram.txt
deleted file mode 100644
index 7da863e..0000000
--- a/simple_er_diagram.txt
+++ /dev/null
@@ -1,142 +0,0 @@
-============================================================
- 宠物医院管理系统 - 实体关系图
-============================================================
-
-┌─────────────┐ ┌─────────────┐
-│ User │◄────────┤ Pet │
-│─────────────│ │─────────────│
-│ id (PK) │ │ id (PK) │
-│ username │ │ owner_id (FK)│
-│ phone │ │ name │
-│ email │ │ species │
-│ password │ │ breed │
-│ role │ │ gender │
-│ status │ │ birthday │
-│ ... │ │ ... │
-└─────────────┘ └─────────────┘
- │ │
- │ │
- │ 1 │ 1..*
- │ │
- ▼ ▼
-┌─────────────┐ ┌─────────────┐
-│ Appointment │◄────────┤ Visit │
-│─────────────│ │─────────────│
-│ id (PK) │ │ id (PK) │
-│ customer_id │ │ appointment │
-│ pet_id (FK) │ │ _id (FK) │
-│ doctor_id │ │ customer_id │
-│ date │ │ pet_id (FK) │
-│ time_slot │ │ doctor_id │
-│ status │ │ symptoms │
-│ ... │ │ diagnosis │
-└─────────────┘ │ ... │
- └─────────────┘
- │
- │
- │ 1
- │
- ▼
-┌─────────────┐ ┌─────────────┐
-│ Doctor │ │Prescription │
-│─────────────│ │─────────────│
-│ id (PK) │◄────────┤ id (PK) │
-│ name │ │ visit_id (FK)│
-│ department │ │ doctor_id │
-│ title │ │ customer_id │
-│ ... │ │ total_amount│
-└─────────────┘ │ status │
- │ ... │
- └─────────────┘
- │
- │ 1
- │
- ▼
- ┌─────────────┐
- │Prescription │
- │ Item │
- │─────────────│
- │ id (PK) │
- │ prescr_id │
- │ (FK) │
- │ drug_id (FK)│
- │ quantity │
- │ ... │
- └─────────────┘
- │
- │
- │ 1
- │
- ▼
- ┌─────────────┐
- │ Drug │
- │─────────────│
- │ id (PK) │
- │ name │
- │ category │
- │ price │
- │ stock_qty │
- │ ... │
- └─────────────┘
- │
- ┌──────────┼──────────┐
- │ │ │
- ▼ ▼ ▼
- ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
- │ Stock In │ │ Stock Out │ │ Order │
- │─────────────│ │─────────────│ │─────────────│
- │ drug_id (FK)│ │ drug_id (FK)│ │ visit_id │
- │ quantity │ │ quantity │ │ (FK) │
- │ ... │ │ ... │ │ amount │
- └─────────────┘ └─────────────┘ │ status │
- │ ... │
- └─────────────┘
-
-============================================================
- 关系说明
-============================================================
-
-1. User (1) ───── (0..*) Pet
- - 一个用户可以拥有零个或多个宠物
-
-2. User (1) ───── (0..*) Appointment
- - 一个用户可以创建零个或多个预约
-
-3. Pet (1) ───── (0..*) Appointment
- - 一个宠物可以有零个或多个预约
-
-4. Doctor (1) ──── (0..*) Appointment
- - 一个医生可以接收零个或多个预约
-
-5. Appointment (0..1) ──── (0..1) Visit
- - 一个预约最多对应一个就诊记录
-
-6. Visit (1) ───── (0..*) Prescription
- - 一个就诊可以开具零个或多个处方
-
-7. Prescription (1) ──── (1..*) PrescriptionItem
- - 一个处方包含一个或多个处方明细
-
-8. Drug (1) ───── (0..*) PrescriptionItem
- - 一种药品可以在零个或多个处方中出现
-
-9. Visit (1) ───── (0..*) Order
- - 一次就诊可以产生零个或多个订单
-
-10. Drug (1) ───── (0..*) StockIn/StockOut
- - 一种药品可以有零个或多个出入库记录
-
-============================================================
- 业务流程
-============================================================
-
-顾客 (User) → 预约 (Appointment) → 就诊 (Visit) →
-处方 (Prescription) → 订单 (Order) → 支付
-
-医生 (User) → 诊断 (Visit) → 开具处方 (Prescription) →
-用药指导 (PrescriptionItem)
-
-药品 (Drug) ←→ 库存管理 (StockIn/StockOut) →
-成本控制 (Order)
-
-============================================================
\ No newline at end of file
diff --git a/thesis_with_diagrams.md b/thesis_with_diagrams.md
deleted file mode 100644
index cb6527d..0000000
--- a/thesis_with_diagrams.md
+++ /dev/null
@@ -1,2059 +0,0 @@
-# 爱维宠物医院管理系统的设计与实现
-
-## 大连科技学院
-
-**信息科学与技术学院**
-**网络工程专业毕业设计(论文)**
-
----
-
-**题目：** 爱维宠物医院管理系统的设计与实现
-**学生姓名：** 关鹏飞
-**学生学号：** 2406490117
-**专业班级：** 网络工程（专升本）24-1
-**指导教师：** 刘鑫
-**职 称：** 工程师
-
-2026年 月 日
-
----
-
-## 摘要
-
-近年来，随着我国居民生活水平的不断提高以及情感需求的逐步增强，宠物已从过去"看家护院"的传统角色，逐渐转变为"家庭成员"般的情感陪伴。根据《2025年中国宠物行业白皮书(消费报告)》数据显示，截至2024年，全国犬猫数量已达到1.2亿只。中国城镇宠物（犬猫）市场规模破3000亿元，预计在2027年将达到4042亿元。
-
-尽管宠物诊疗机构数量已突破2.3万家，行业内仍存在集中度低、信息化程度欠缺以及服务流程规范性不足等诸多待解决的问题。例如，病历以手写形式记录导致易丢失，预约挂号时的长队现象、疫苗与驱虫信息分散、收费项目缺乏透明性等问题，不仅增加了宠物主人的时间成本与心理负担，同时也对宠物医院的运营效率和品牌口碑构成了明显的制约。
-
-本课题聚焦于"爱维宠物医院管理平台"的设计与实现，旨在围绕"提升医院运营效率、优化宠物主就诊体验、保障诊疗数据安全"这三大核心目标，开发出一套包含预约挂号、病历管理、药品库存、收费结算、疫苗驱虫提醒以及数据统计分析等主要功能的信息化系统。
-
-系统采用Spring Boot作为后端框架，结合MySQL数据库和Vue.js前端技术，实现了前后端分离的架构。通过角色权限管理（RBAC），系统为管理员、宠物医生和顾客提供了差异化的功能支持。管理员可以进行全局管理，包括员工账号管理、药品库存管理、统计报表等；医生可以处理门诊接待、病历记录、处方开具等诊疗业务；顾客可以在线预约、查看宠物档案、查询报告等。
-
-通过系统测试验证，该平台能够有效提升宠物医院的运营效率，减少人工处理数据的时间，降低出错几率，并为宠物主人提供便捷的在线服务，增强用户的黏性和信任感。
-
-**关键词：** Spring Boot；宠物医院；管理系统；MySQL；前后端分离
-
----
-
-## Abstract
-
-In recent years, with the continuous improvement of residents' living standards and the gradual enhancement of emotional needs, pets have gradually transformed from the traditional role of "watchdog" to that of emotional companionship as "family members." According to the "2025 China Pet Industry White Paper (Consumer Report)", by 2024, the number of dogs and cats nationwide had reached 120 million. The scale of China's urban pet (dogs and cats) market has exceeded 300 billion yuan and is expected to reach 404.2 billion yuan by 2027.
-
-Although the number of pet medical institutions has exceeded 23,000, there are still many unsolved problems in the industry, such as low concentration, insufficient informatization, and inadequate standardization of service processes. For example, handwritten medical records are easily lost, long queues during appointment registration, scattered vaccination and deworming information, and lack of transparency in charging items not only increase the time cost and psychological burden of pet owners, but also impose obvious constraints on the operational efficiency and brand reputation of pet hospitals.
-
-This topic focuses on the design and implementation of the "Aiwei Pet Hospital Management Platform," aiming at the three core goals of "improving hospital operational efficiency, optimizing pet owner's medical experience, and ensuring medical data security," to develop an information system that includes major functions such as appointment registration, medical record management, drug inventory, fee settlement, vaccination and deworming reminders, and data statistics and analysis.
-
-The system adopts Spring Boot as the backend framework, combined with MySQL database and Vue.js frontend technology, achieving a separation of frontend and backend architecture. Through role-based permission management (RBAC), the system provides differentiated functional support for administrators, pet doctors, and customers. Administrators can perform global management, including employee account management, drug inventory management, statistical reports, etc.; doctors can handle medical services such as outpatient reception, medical record recording, and prescription issuance; customers can make online appointments, view pet profiles, and query reports.
-
-Through system testing and verification, the platform can effectively improve the operational efficiency of pet hospitals, reduce the time spent manually processing data, decrease the likelihood of errors, and provide convenient online services for pet owners, enhancing user stickiness and trust.
-
-**Keywords:** Spring Boot; Pet Hospital; Management System; MySQL; Frontend-backend Separation
-
----
-
-## 目录
-
-- [第一章 绪论](#第一章-绪论)
- - [1.1 课题来源及意义](#11-课题来源及意义)
- - [1.2 课题研究现状](#12-课题研究现状)
- - [1.3 当前存在的问题](#13-当前存在的问题)
- - [1.4 课题研究目标](#14-课题研究目标)
- - [1.5 论文组织结构](#15-论文组织结构)
-- [第二章 主要技术和框架](#第二章-主要技术和框架)
- - [2.1 主要技术](#21-主要技术)
- - [2.2 框架和开发模式](#22-框架和开发模式)
-- [第三章 爱维宠物医院管理系统的系统分析](#第三章-爱维宠物医院管理系统的系统分析)
- - [3.1 需求分析](#31-需求分析)
- - [3.2 可行性分析](#32-可行性分析)
- - [3.3 用例图](#33-用例图)
- - [3.4 用例描述](#34-用例描述)
- - [3.5 系统性能分析](#35-系统性能分析)
-- [第四章 爱维宠物医院管理系统的系统设计](#第四章-爱维宠物医院管理系统的系统设计)
- - [4.1 系统功能设计](#41-系统功能设计)
- - [4.2 类图](#42-类图)
- - [4.3 序列图](#43-序列图)
- - [4.4 活动图](#44-活动图)
- - [4.5 数据库设计](#45-数据库设计)
- - [4.6 图形界面设计](#46-图形界面设计)
-- [第五章 爱维宠物医院管理系统的系统实现](#第五章-爱维宠物医院管理系统的系统实现)
- - [5.1 开发环境搭建](#51-开发环境搭建)
- - [5.2 核心功能模块实现](#52-核心功能模块实现)
- - [5.3 前后端交互实现](#53-前后端交互实现)
- - [5.4 关键技术实现](#54-关键技术实现)
-- [第六章 爱维宠物医院管理系统的系统测试](#第六章-爱维宠物医院管理系统的系统测试)
- - [6.1 系统测试概述](#61-系统测试概述)
- - [6.2 系统测试用例设计](#62-系统测试用例设计)
- - [6.3 测试结果分析](#63-测试结果分析)
-- [第七章 总结与展望](#第七章-总结与展望)
- - [7.1 工作总结](#71-工作总结)
- - [7.2 系统特色与创新点](#72-系统特色与创新点)
- - [7.3 不足与展望](#73-不足与展望)
-- [参考文献](#参考文献)
-- [致谢](#致谢)
-
----
-
-## 第一章 绪论
-
-### 1.1 课题来源及意义
-
-#### 1.1.1 课题来源
-
-随着社会经济的发展和人们生活水平的提高，宠物在人们生活中的地位日益重要。宠物不再仅仅是看家护院的工具，而是成为了人们情感寄托的重要伙伴。据统计，我国宠物市场规模持续扩大，宠物数量快速增长，宠物医疗需求也随之增加。然而，传统的宠物医院管理模式存在诸多弊端，如手工记录、信息孤立、效率低下等问题，严重影响了宠物医院的服务质量和运营效率。
-
-在此背景下，本课题提出开发一套现代化的宠物医院管理系统——爱维宠物医院管理系统，以解决传统管理模式的痛点，提高宠物医院的管理水平和服务质量。
-
-#### 1.1.2 课题意义
-
-本课题的研究与实现具有重要的理论和实践意义：
-
-**理论意义：**
-1. 丰富了"互联网+宠物医疗"场景下的信息系统设计理论
-2. 为后续开展宠物健康大数据分析及远程诊疗等相关研究提供坚实的理论基础
-3. 探索了传统服务业信息化转型的路径和方法
-
-**实践意义：**
-1. 为中小型宠物医院提供了一套低成本、可复制、可扩展的信息化解决方案
-2. 提升宠物医院的运营效率，降低人力成本
-3. 改善宠物主人的就诊体验，增强用户粘性
-4. 推动宠物医疗行业的数字化转型
-
-### 1.2 课题研究现状
-
-#### 1.2.1 国外研究现状
-
-国外在宠物医院管理系统的研究和应用方面起步较早，并在管理智能化与服务创新方面走在了前列。欧美国家和地区的宠物医院管理平台，通过整合大数据、云计算和人工智能技术，形成了更加全面、便捷且个性化的服务体系。许多发达国家如美国、英国和澳大利亚，宠物医院管理系统不仅具备预约诊疗、处方管理等基础功能，还加入了远程医疗功能及在线咨询模块，旨在为宠物主人与宠物医生之间提供更加及时高效的沟通渠道。
-
-同时，国外宠物医院系统在药品管理与财务报表呈现等方面更强调数据分析能力。通过结合宠物医疗数据和区域病情信息，许多系统具备预测疾病流行趋势的能力，以支持医院药品库存和服务资源的规划。
-
-#### 1.2.2 国内研究现状
-
-国内宠物医院管理研究主要集中在信息管理平台的开发和服务流程的系统化上。许多学者致力于构建宠物医院的管理信息系统，重点解决门诊预约管理、宠物档案建立、医疗记录存档、药品库存管理、订单支付等问题，以此提升宠物医院运营的效率，同时改善宠物主人的服务体验。
-
-例如，有研究针对门诊预约和宠物档案管理的双向结合提出了数字化解决方案，通过信息化技术实现宠物医疗记录的自动存档与高效检索，从而减少了人工处理数据的时间。而另一部分研究则更加关注宠物主人与宠物医院之间的交互体验探索移动终端应用，提高动态数据的可追溯性和服务的精准性。
-
-### 1.3 当前存在的问题
-
-通过对多家宠物医院的实地调研和问卷调查，发现当前宠物医院管理中存在的主要问题包括：
-
-#### 1.3.1 数据管理问题
-
-1. **病历记录方式落后**：大部分宠物医院仍采用手写病历的方式，存在易丢失、难查找、字迹模糊等问题
-2. **数据孤岛现象严重**：各部门之间信息不通畅，数据无法共享
-3. **数据统计困难**：缺乏有效的数据分析工具，难以进行经营决策支持
-
-#### 1.3.2 服务流程问题
-
-1. **预约流程低效**：传统电话预约或现场挂号方式导致排队现象严重
-2. **服务透明度不足**：收费项目缺乏透明性，容易引起纠纷
-3. **客户体验差**：等待时间长，服务效率低
-
-#### 1.3.3 运营管理问题
-
-1. **库存管理混乱**：药品和耗材的进出库记录不准确，经常出现断货或积压
-2. **人员管理困难**：缺乏有效的员工绩效考核和排班管理
-3. **财务管理不规范**：收入支出记录不清晰，难以进行财务分析
-
-### 1.4 课题研究目标
-
-本课题的研究目标是设计并实现一套功能完善的爱维宠物医院管理系统，具体目标如下：
-
-#### 1.4.1 总体目标
-
-构建一个集预约挂号、病历管理、药品库存、收费结算、数据统计等功能于一体的综合性管理平台，实现宠物医院业务流程的数字化和智能化。
-
-#### 1.4.2 具体目标
-
-1. **实现多角色权限管理**：为管理员、医生、顾客提供差异化的功能支持
-2. **建立完整的宠物档案管理**：记录宠物基本信息、疫苗接种、病史等
-3. **优化预约流程**：提供在线预约功能，减少排队等待时间
-4. **规范病历管理**：实现电子病历，便于查询和统计
-5. **完善药品库存管理**：跟踪药品的采购、库存、销售全流程
-6. **提供数据统计分析**：为经营管理提供决策支持
-
-### 1.5 论文组织结构
-
-本论文共分为七章，具体组织结构如下：
-
-第一章：绪论。介绍课题的来源、意义、研究现状、存在问题及研究目标。
-
-第二章：主要技术和框架。介绍系统开发所采用的关键技术和框架，包括Java、Spring Boot、MySQL、Vue.js等。
-
-第三章：系统分析。对爱维宠物医院管理系统进行全面的需求分析，包括功能需求、性能需求、可行性分析等。
-
-第四章：系统设计。详细阐述系统的整体架构、功能模块设计、数据库设计、界面设计等。
-
-第五章：系统实现。介绍系统的开发过程，包括环境搭建、核心模块实现、前后端交互等。
-
-第六章：系统测试。描述系统的测试方案、测试用例及测试结果分析。
-
-第七章：总结与展望。总结本文的主要工作，分析系统的特色与不足，展望未来改进方向。
-
----
-
-## 第二章 主要技术和框架
-
-### 2.1 主要技术
-
-#### 2.1.1 Java开发语言
-
-Java是一种广泛使用的面向对象编程语言，具有跨平台、健壮性强、安全性高等特点。在企业级应用开发中，Java凭借其成熟的生态系统和丰富的框架支持，成为首选的开发语言。
-
-**Java的主要特点：**
-1. **跨平台性**：一次编写，到处运行（Write Once, Run Anywhere）
-2. **面向对象**：支持封装、继承、多态等面向对象特性
-3. **健壮性**：强类型检查、异常处理机制
-4. **安全性**：沙箱机制、安全管理器
-5. **多线程支持**：内置多线程支持，提高程序执行效率
-
-#### 2.1.2 Spring Boot框架
-
-Spring Boot是基于Spring框架的快速开发脚手架，它简化了Spring应用的初始搭建以及开发过程。Spring Boot通过约定大于配置的理念，让开发者能够快速构建独立的、生产级别的基于Spring框架的应用程序。
-
-**Spring Boot的核心特性：**
-1. **自动配置**：根据类路径中的jar包自动配置Spring
-2. **起步依赖**：简化了Maven/Gradle配置
-3. **嵌入式服务器**：内置Tomcat、Jetty或Undertow
-4. **生产就绪特性**：提供监控、指标收集等功能
-
-#### 2.1.3 MySQL数据库
-
-MySQL是一个流行的开源关系型数据库管理系统，以其高性能、可靠性和易用性著称。在Web应用开发中，MySQL被广泛用于数据持久化存储。
-
-**MySQL的特点：**
-1. **开源免费**：降低了使用成本
-2. **高性能**：支持大容量数据存储和高并发访问
-3. **跨平台**：支持多种操作系统
-4. **丰富的功能**：支持事务、存储过程、触发器等
-
-#### 2.1.4 MyBatis-Plus
-
-MyBatis-Plus是MyBatis的增强工具，简化了MyBatis的使用，提供了通用的CRUD操作，极大地提高了开发效率。
-
-**MyBatis-Plus的优势：**
-1. **无侵入**：只做增强不做改变
-2. **损耗小**：启动即会自动注入基本的CRUD
-3. **强大的CRUD操作**：内置通用Mapper、通用Service
-4. **支持Lambda形式调用**：通过Lambda表达式，方便的编写各类查询条件
-
-#### 2.1.5 Vue.js前端框架
-
-Vue.js是一套用于构建用户界面的渐进式JavaScript框架，易于上手且功能强大，适合构建单页面应用。
-
-**Vue.js的特点：**
-1. **渐进式框架**：可以逐步采用
-2. **组件化**：可复用的组件系统
-3. **响应式数据绑定**：数据变化自动更新视图
-4. **轻量级**：体积小，性能优秀
-
-### 2.2 框架和开发模式
-
-#### 2.2.1 前后端分离架构
-
-本系统采用前后端分离的架构模式，前端使用Vue.js构建用户界面，后端使用Spring Boot提供RESTful API接口。这种架构模式的优点包括：
-
-1. **职责分离**：前后端职责分离，各自专注于自身领域
-2. **接口复用**：同一套API可以支持多种客户端
-3. **技术栈灵活**：前后端可以选择最适合的技术栈
-4. **开发效率高**：前后端可并行开发
-
-#### 2.2.2 RBAC权限模型
-
-基于角色的访问控制（Role-Based Access Control）是一种广泛使用的权限管理模型。本系统通过RBAC模型实现了对不同用户角色的权限管理。
-
-**RBAC模型的核心概念：**
-1. **用户（User）**：系统的使用者
-2. **角色（Role）**：权限的集合
-3. **权限（Permission）**：对资源的操作权限
-4. **用户-角色关系**：用户可以拥有多个角色
-5. **角色-权限关系**：角色包含多个权限
-
-#### 2.2.3 RESTful API设计
-
-系统后端采用RESTful API设计风格，通过HTTP动词映射资源的CRUD操作，使接口设计更加规范和一致。
-
-**RESTful API设计原则：**
-1. **资源导向**：以资源为中心设计API
-2. **统一接口**：使用标准HTTP动词（GET、POST、PUT、DELETE）
-3. **无状态**：每个请求都包含所有必要信息
-4. **可缓存**：适当利用HTTP缓存机制
-
----
-
-## 第三章 爱维宠物医院管理系统的系统分析
-
-### 3.1 需求分析
-
-#### 3.1.1 功能需求分析
-
-##### 3.1.1.1 管理员功能需求
-
-**账户管理模块：**
-1. **员工账号管理**：添加、编辑、删除员工账号，分配角色权限
- - 支持批量导入员工信息
- - 可设置员工状态（启用/禁用）
- - 支持重置员工密码
-2. **顾客账号管理**：查看、禁用顾客账号
- - 可查看顾客基本信息和消费记录
- - 可禁用违规顾客账号
-3. **权限管理**：为不同角色分配操作权限
- - 基于RBAC模型的细粒度权限控制
- - 支持权限的动态分配和回收
-
-**药品管理模块：**
-1. **药品资料管理**：维护药品基础信息
- - 药品名称、规格、生产厂家、价格等
- - 药品分类管理
- - 药品有效期管理
-2. **库存管理**：跟踪药品进出库情况
- - 入库管理：记录采购入库信息
- - 出库管理：记录销售或损耗出库
- - 库存盘点：定期核对实际库存
-3. **预警管理**：设置库存预警机制
- - 低库存预警：库存低于阈值时提醒
- - 过期预警：药品临近过期时提醒
-
-**公告管理模块：**
-1. **发布公告**：发布、编辑、置顶、下架公告
-2. **公告分类**：按类型分类管理公告
-
-**统计报表模块：**
-1. **收入报表**：按时间段统计收入情况
- - 日报、周报、月报
- - 按医生、科室、服务类型统计
-2. **运营报表**：统计医院运营指标
- - 患者流量统计
- - 服务项目热度分析
-3. **导出功能**：支持报表导出为Excel格式
-
-##### 3.1.1.2 医生功能需求
-
-**门诊管理模块：**
-1. **预约管理**：查看和处理预约信息
- - 查看当日预约列表
- - 确认患者到达状态
- - 取消或调整预约
-2. **接诊管理**：处理现场患者
- - 创建临时就诊记录
- - 分诊和排队管理
-3. **病历管理**：记录诊疗过程
- - 创建和编辑病历
- - 上传检查报告
- - 添加医嘱
-
-**处方管理模块：**
-1. **处方开具**：为患者开具电子处方
- - 选择药品和用量
- - 设置用药频次和疗程
- - 添加特殊说明
-2. **处方查询**：查看历史处方记录
- - 按患者查询处方记录
- - 按药品查询使用情况
-3. **处方打印**：打印电子处方
- - 标准处方格式
- - 支持批量打印
-
-**患者管理功能：**
-1. **患者档案**：查看患者基本信息
- - 个人资料
- - 宠物档案
- - 历史病历
-2. **健康评估**：记录患者健康状况
- - 体检记录
- - 疫苗接种记录
- - 过敏史等
-
-##### 3.1.1.3 顾客功能需求
-
-**个人中心功能：**
-1. **账户管理**：管理个人信息
- - 修改基本信息
- - 更改登录密码
- - 管理收货地址
-2. **宠物管理**：维护宠物档案
- - 添加新宠物
- - 编辑宠物信息
- - 记录疫苗接种
-
-**预约服务功能：**
-1. **在线预约**：预约门诊服务
- - 选择医生和时间
- - 选择就诊宠物
- - 添加预约备注
-2. **预约管理**：管理预约记录
- - 查看预约状态
- - 取消预约
- - 预约提醒
-
-**查询服务功能：**
-1. **病历查询**：查看历史病历
- - 按宠物查询
- - 按时间查询
- - 下载病历
-2. **处方查询**：查看历史处方
- - 查看用药说明
- - 重复开药申请
-3. **报告查询**：查看检查报告
- - 图片报告查看
- - 文字报告下载
-
-#### 3.1.2 性能需求分析
-
-##### 3.1.2.1 响应时间要求
-1. **页面加载时间**：一般页面加载时间不超过3秒
-2. **数据查询时间**：普通查询响应时间不超过2秒
-3. **数据更新时间**：数据更新操作响应时间不超过1秒
-
-##### 3.1.2.2 并发性能要求
-1. **并发用户数**：系统应支持不少于100个并发用户
-2. **数据库连接**：数据库连接池大小应适应并发需求
-3. **负载均衡**：在高并发情况下保证系统稳定运行
-
-##### 3.1.2.3 数据安全要求
-1. **数据加密**：敏感数据应进行加密存储
-2. **传输安全**：数据传输应使用HTTPS协议
-3. **访问控制**：严格的权限控制，防止越权访问
-
-### 3.2 可行性分析
-
-#### 3.2.1 技术可行性
-
-本系统的开发基于成熟的技术框架和工具，如Java开发语言、Spring Boot框架、MySQL数据库、HTML、CSS及JavaScript等前端技术。现有的技术和工具能够完全支持宠物医院管理系统的开发与实现，保障系统的高效运行。
-
-通过Spring Boot框架可以实现灵活的后台管理功能，如药品库存管理、数据统计等，确保数据交互的稳定性和安全性。同时，前端技术成熟，可以为顾客提供简洁、直观且友好的交互界面。
-
-此外，系统采用模块化设计，使得功能扩展性和可维护性较高，未来可根据宠物医院的实际需求进行功能调整和升级。从技术角度来看，本研究方案是可行的。
-
-#### 3.2.2 经济可行性
-
-在经济方面，系统的开发和运行成本相对较低。本系统采用开源技术和工具，包括Spring Boot、MySQL数据库和Vue.js，这能有效降低软件开发和维护的许可费用。
-
-硬件方面，宠物医院可以利用现有的计算机设备来部署该系统，无需购买额外的硬件，进一步降低建设成本。系统上线后，由于信息化管理提升了运营效率，能够减少人工工作量、操作复杂性和人为出错几率，从而降低医院的运营成本。
-
-此外，系统维护仅需安排一名系统管理员即可，维护成本相对较低。总体而言，系统的开发和运行成本合理，具有较高的经济可行性。
-
-#### 3.2.3 社会可行性
-
-随着人们对宠物健康管理需求的增加，宠物医院信息化管理逐渐成为行业发展的趋势。本系统的开发有助于提升宠物医院的服务质量和管理效率，为客户提供便捷的在线服务，例如预约门诊、报告查询、宠物档案管理等功能。
-
-同时，管理员和宠物医生可以通过系统优化医院资源的管理，如药品库存监控、报表生成等功能，从而提升工作效率和服务质量。
-
-从社会可行性来看，系统能够显著提高宠物医院的服务水平，增强宠物主人和医院管理者的满意度，具有较大的社会价值。因此，社会对该系统的需求较高，社会可行性较强。
-
-### 3.3 用例图
-
-下面是系统的用例图，展示了不同角色的用户与系统功能之间的交互关系：
-
-```mermaid
-graph TD
- subgraph "系统边界"
- S[爱维宠物医院管理系统]
- end
-
- subgraph "参与者"
- U[顾客]
- D[医生]
- A[管理员]
- end
-
- subgraph "用例"
- UC1[注册/登录]
- UC2[管理个人资料]
- UC3[管理宠物档案]
- UC4[进行预约挂号]
- UC5[查看预约记录]
- UC6[查看病历和处方]
- UC7[查询报告]
- UC8[进行支付]
-
- UC9[管理员工账号]
- UC10[管理顾客账号]
- UC11[管理药品库存]
- UC12[管理公告]
- UC13[查看统计报表]
- UC14[管理预约记录]
- UC15[管理病历记录]
- UC16[管理宠物档案]
-
- UC17[门诊管理]
- UC18[病历管理]
- UC19[处方管理]
- UC20[宠物信息查询]
- end
-
- U --> UC1
- U --> UC2
- U --> UC3
- U --> UC4
- U --> UC5
- U --> UC6
- U --> UC7
- U --> UC8
-
- A --> UC9
- A --> UC10
- A --> UC11
- A --> UC12
- A --> UC13
- A --> UC14
- A --> UC15
- A --> UC16
-
- D --> UC17
- D --> UC18
- D --> UC19
- D --> UC20
-
- S --> UC1
- S --> UC2
- S --> UC3
- S --> UC4
- S --> UC5
- S --> UC6
- S --> UC7
- S --> UC8
- S --> UC9
- S --> UC10
- S --> UC11
- S --> UC12
- S --> UC13
- S --> UC14
- S --> UC15
- S --> UC16
- S --> UC17
- S --> UC18
- S --> UC19
- S --> UC20
-```
-
-### 3.4 用例描述
-
-#### 3.4.1 预约挂号用例描述
-
-| 用例名称 | 预约挂号 |
-|---------|----------|
-| 执行者 | 顾客 |
-| 简要说明 | 顾客在线预约门诊服务 |
-| 基本事件流 | 1.顾客登录系统，进入预约界面
2.系统显示可预约的时间段
3.顾客选择医生、时间段和宠物
4.系统验证时段可用性
5.顾客确认预约信息并提交
6.系统保存预约记录并返回确认信息 |
-| 扩展事件流 | 2a.系统无可用时段：提示顾客选择其他时间
3a.顾客未登录：跳转到登录页面 |
-| 前置条件 | 顾客已注册并登录 |
-| 后置条件 | 预约记录已创建 |
-
-#### 3.4.2 病历管理用例描述
-
-| 用例名称 | 创建病历 |
-|---------|----------|
-| 执行者 | 医生 |
-| 简要说明 | 医生为就诊的宠物创建病历 |
-| 基本事件流 | 1.医生登录系统，进入病历管理界面
2.选择就诊记录
3.录入症状、检查结果、诊断结论等信息
4.系统验证信息完整性
5.医生确认并保存病历
6.系统返回保存成功信息 |
-| 扩展事件流 | 3a.信息不完整：系统提示补充必要信息
3b.患者信息错误：返回修正患者信息 |
-| 前置条件 | 医生已登录，患者已完成就诊 |
-| 后置条件 | 病历记录已创建并保存 |
-
-#### 3.4.3 药品管理用例描述
-
-| 用例名称 | 药品入库 |
-|---------|----------|
-| 执行者 | 管理员 |
-| 简要说明 | 管理员记录药品入库信息 |
-| 基本事件流 | 1.管理员登录系统，进入药品管理界面
2.选择入库操作
3.录入药品信息、数量、供应商等信息
4.系统验证药品信息有效性
5.管理员确认并保存入库记录
6.系统更新库存并返回成功信息 |
-| 扩展事件流 | 3a.药品信息错误：提示重新输入正确信息
3b.权限不足：拒绝操作 |
-| 前置条件 | 管理员已登录并有相应权限 |
-| 后置条件 | 药品库存已更新 |
-
-### 3.5 系统性能分析
-
-#### 3.5.1 响应性能分析
-
-系统在设计时充分考虑了性能因素，通过合理的架构设计和优化措施，确保系统能够满足高并发、低延迟的性能要求。主要性能指标包括响应时间、吞吐量、并发用户数和支持的数据量等方面。
-
-#### 3.5.2 数据安全分析
-
-系统采用多层次的安全防护措施，包括用户身份认证、权限控制、数据加密、操作日志等，确保数据的安全性和完整性。
-
-#### 3.5.3 系统稳定性分析
-
-通过采用微服务架构、负载均衡、故障转移等技术手段，确保系统在面对各种异常情况时仍能稳定运行。
-
----
-
-## 第四章 爱维宠物医院管理系统的系统设计
-
-### 4.1 系统功能设计
-
-#### 4.1.1 管理员功能设计
-
-管理员角色拥有系统的最高权限，主要负责全局管理和监督。其功能包括：
-
-**账户管理功能：**
-1. **员工管理**：添加、编辑、删除员工账号，分配角色权限
- - 支持批量导入员工信息
- - 可设置员工状态（启用/禁用）
- - 支持重置员工密码
-2. **顾客管理**：查看、禁用顾客账号
- - 可查看顾客基本信息和消费记录
- - 可禁用违规顾客账号
-3. **权限管理**：为不同角色分配操作权限
- - 基于RBAC模型的细粒度权限控制
- - 支持权限的动态分配和回收
-
-**药品管理功能：**
-1. **药品资料管理**：维护药品基础信息
- - 药品名称、规格、生产厂家、价格等
- - 药品分类管理
- - 药品有效期管理
-2. **库存管理**：跟踪药品进出库情况
- - 入库管理：记录采购入库信息
- - 出库管理：记录销售或损耗出库
- - 库存盘点：定期核对实际库存
-3. **预警管理**：设置库存预警机制
- - 低库存预警：库存低于阈值时提醒
- - 过期预警：药品临近过期时提醒
-
-**统计报表功能：**
-1. **收入报表**：按时间段统计收入情况
- - 日报、周报、月报
- - 按医生、科室、服务类型统计
-2. **运营报表**：统计医院运营指标
- - 患者流量统计
- - 服务项目热度分析
-3. **导出功能**：支持报表导出为Excel格式
-
-#### 4.1.2 医生功能设计
-
-医生角色主要负责诊疗业务，其功能包括：
-
-**门诊管理功能：**
-1. **预约管理**：查看和处理预约信息
- - 查看当日预约列表
- - 确认患者到达状态
- - 取消或调整预约
-2. **接诊管理**：处理现场患者
- - 创建临时就诊记录
- - 分诊和排队管理
-3. **病历管理**：记录诊疗过程
- - 创建和编辑病历
- - 上传检查报告
- - 添加医嘱
-
-**处方管理功能：**
-1. **处方开具**：为患者开具电子处方
- - 选择药品和用量
- - 设置用药频次和疗程
- - 添加特殊说明
-2. **处方查询**：查看历史处方
- - 按患者查询处方记录
- - 按药品查询使用情况
-3. **处方打印**：打印电子处方
- - 标准处方格式
- - 支持批量打印
-
-**患者管理功能：**
-1. **患者档案**：查看患者基本信息
- - 个人资料
- - 宠物档案
- - 历史病历
-2. **健康评估**：记录患者健康状况
- - 体检记录
- - 疫苗接种记录
- - 过敏史等
-
-#### 4.1.3 顾客功能设计
-
-顾客角色主要使用前台功能，其功能包括：
-
-**个人中心功能：**
-1. **账户管理**：管理个人信息
- - 修改基本信息
- - 更改登录密码
- - 管理收货地址
-2. **宠物管理**：维护宠物档案
- - 添加新宠物
- - 编辑宠物信息
- - 记录疫苗接种
-
-**预约服务功能：**
-1. **在线预约**：预约门诊服务
- - 选择医生和时间
- - 选择就诊宠物
- - 添加预约备注
-2. **预约管理**：管理预约记录
- - 查看预约状态
- - 取消预约
- - 预约提醒
-
-**查询服务功能：**
-1. **病历查询**：查看历史病历
- - 按宠物查询
- - 按时间查询
- - 下载病历
-2. **处方查询**：查看历史处方
- - 查看用药说明
- - 重复开药申请
-3. **报告查询**：查看检查报告
- - 图片报告查看
- - 文字报告下载
-
-### 4.2 类图
-
-以下是系统的类图，展示了各个实体类及其关系：
-
-```mermaid
-classDiagram
- class User {
- +Long id
- +String username
- +String phone
- +String email
- +String password
- +String role
- +Integer status
- +String avatar
- +LocalDateTime createTime
- +LocalDateTime updateTime
- +Integer deleted
- +setters/getters()
- }
-
- class Doctor {
- +Long id
- +String name
- +String department
- +String title
- +String phone
- +String email
- +String avatar
- +Integer status
- +LocalDateTime createTime
- +LocalDateTime updateTime
- +Integer deleted
- +setters/getters()
- }
-
- class Pet {
- +Long id
- +Long ownerId
- +String name
- +String species
- +String breed
- +String gender
- +LocalDate birthday
- +Double weight
- +String photo
- +String remark
- +LocalDateTime createTime
- +LocalDateTime updateTime
- +Integer deleted
- +setters/getters()
- }
-
- class Appointment {
- +Long id
- +Long customerId
- +Long petId
- +Long doctorId
- +String department
- +LocalDate appointmentDate
- +String timeSlot
- +String status
- +String remark
- +LocalDateTime cancelTime
- +LocalDateTime createTime
- +LocalDateTime updateTime
- +Integer deleted
- +setters/getters()
- }
-
- class Visit {
- +Long id
- +Long appointmentId
- +Long customerId
- +Long petId
- +Long doctorId
- +String symptoms
- +String diagnosis
- +String treatmentPlan
- +String status
- +BigDecimal totalAmount
- +String paymentStatus
- +String paymentMethod
- +LocalDateTime paymentTime
- +LocalDateTime startTime
- +LocalDateTime endTime
- +LocalDateTime createTime
- +LocalDateTime updateTime
- +Integer deleted
- +setters/getters()
- }
-
- class MedicalRecord {
- +Long id
- +Long visitId
- +String recordType
- +String content
- +String attachmentUrls
- +Long doctorId
- +LocalDateTime createTime
- +LocalDateTime updateTime
- +Integer deleted
- +setters/getters()
- }
-
- class Prescription {
- +Long id
- +Long visitId
- +Long doctorId
- +Long customerId
- +BigDecimal totalAmount
- +String status
- +String remark
- +LocalDateTime createTime
- +LocalDateTime updateTime
- +Integer deleted
- +setters/getters()
- }
-
- class Drug {
- +Long id
- +String name
- +String category
- +String manufacturer
- +String specification
- +BigDecimal unitPrice
- +Integer stockQuantity
- +String unit
- +Integer status
- +LocalDateTime createTime
- +LocalDateTime updateTime
- +Integer deleted
- +setters/getters()
- }
-
- User ||--o{ Pet : "owns"
- User ||--o{ Appointment : "makes"
- Doctor ||--o{ Appointment : "handles"
- Pet ||--o{ Appointment : "involved_in"
- Appointment ||--|| Visit : "results_in"
- User ||--o{ Visit : "undergoes"
- Pet ||--o{ Visit : "involved_in"
- Doctor ||--o{ Visit : "conducts"
- Visit ||--o{ MedicalRecord : "generates"
- Doctor ||--o{ MedicalRecord : "creates"
- Visit ||--o{ Prescription : "generates"
- Doctor ||--o{ Prescription : "creates"
- User ||--o{ Prescription : "receives"
-```
-
-### 4.3 序列图
-
-下面展示预约挂号的序列图：
-
-```mermaid
-sequenceDiagram
- participant Customer as 顾客
- participant System as 系统
- participant AppointmentService as 预约服务
- participant Database as 数据库
-
- Customer->>System: 登录系统
- System->>Database: 验证用户身份
- Database-->>System: 返回验证结果
- System-->>Customer: 登录成功
-
- Customer->>System: 请求可预约时间段
- System->>AppointmentService: 查询可用时间段
- AppointmentService->>Database: 查询预约数据
- Database-->>AppointmentService: 返回可用时间段
- AppointmentService-->>System: 返回可用时间段
- System-->>Customer: 显示可预约时间段
-
- Customer->>System: 选择医生、时间段和宠物
- System->>AppointmentService: 验证时段可用性
- AppointmentService->>Database: 检查时段是否已被预约
- Database-->>AppointmentService: 返回验证结果
- AppointmentService-->>System: 验证通过
-
- Customer->>System: 确认预约信息
- System->>AppointmentService: 创建预约记录
- AppointmentService->>Database: 保存预约信息
- Database-->>AppointmentService: 保存成功
- AppointmentService-->>System: 预约创建成功
- System-->>Customer: 预约确认信息
-```
-
-### 4.4 活动图
-
-下面是医生接诊流程的活动图：
-
-```mermaid
-flowchart TD
- A[开始] --> B[医生登录系统]
- B --> C[系统验证医生身份]
- C --> D{身份验证成功?}
- D -->|否| E[显示错误信息]
- D -->|是| F[查看预约列表]
- F --> G[选择患者]
- G --> H[确认患者到达]
- H --> I[创建就诊记录]
- I --> J[询问症状]
- J --> K[体格检查]
- K --> L[诊断分析]
- L --> M[记录病历]
- M --> N{需要开具处方?}
- N -->|是| O[开具处方]
- N -->|否| P[更新就诊状态]
- O --> P
- P --> Q[结束就诊]
- Q --> R[保存记录]
- R --> S[结束]
- E --> T[结束]
-```
-
-### 4.5 数据库设计
-
-#### 4.5.1 概念设计
-
-系统涉及的主要实体包括：用户、医生、宠物、预约、就诊记录、病历、处方、药品、订单、公告、消息、疫苗记录、入库记录、出库记录、统计报表等。
-
-**实体关系：**
-- 用户与宠物：一对多（一个用户可以拥有多只宠物）
-- 用户与预约：一对多（一个用户可以有多个预约）
-- 医生与预约：一对多（一个医生可以有多个预约）
-- 预约与就诊：一对一（一个预约对应一次就诊）
-- 就诊与病历：一对多（一次就诊可以有多个病历记录）
-- 就诊与处方：一对多（一次就诊可以开具多个处方）
-- 处方与药品：多对多（通过处方项关联）
-- 药品与库存记录：一对多（一个药品可以有多个出入库记录）
-
-下面是数据库的实体关系图：
-
-```mermaid
-erDiagram
- USER {
- bigint id PK
- varchar username UK
- varchar phone
- varchar email
- varchar password
- varchar role
- int status
- varchar avatar
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- DOCTOR {
- bigint id PK
- varchar name
- varchar department
- varchar title
- varchar phone
- varchar email
- varchar avatar
- int status
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- PET {
- bigint id PK
- bigint owner_id FK
- varchar name
- varchar species
- varchar breed
- varchar gender
- date birthday
- double weight
- varchar photo
- text remark
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- APPOINTMENT {
- bigint id PK
- bigint customer_id FK
- bigint pet_id FK
- bigint doctor_id FK
- varchar department
- date appointment_date
- varchar time_slot
- varchar status
- text remark
- timestamp cancel_time
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- VISIT {
- bigint id PK
- bigint appointment_id FK
- bigint customer_id FK
- bigint pet_id FK
- bigint doctor_id FK
- text symptoms
- text diagnosis
- text treatment_plan
- varchar status
- decimal total_amount
- varchar payment_status
- varchar payment_method
- timestamp payment_time
- timestamp start_time
- timestamp end_time
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- MEDICAL_RECORD {
- bigint id PK
- bigint visit_id FK
- varchar record_type
- text content
- text attachment_urls
- bigint doctor_id FK
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- PRESCRIPTION {
- bigint id PK
- bigint visit_id FK
- bigint doctor_id FK
- bigint customer_id FK
- decimal total_amount
- varchar status
- text remark
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- DRUG {
- bigint id PK
- varchar name
- varchar category
- varchar manufacturer
- varchar specification
- decimal unit_price
- int stock_quantity
- varchar unit
- int status
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- PRESCRIPTION_ITEM {
- bigint id PK
- bigint prescription_id FK
- bigint drug_id FK
- int quantity
- varchar dosage
- varchar frequency
- varchar duration
- text usage_instructions
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- STOCK_IN {
- bigint id PK
- bigint drug_id FK
- int quantity
- decimal unit_price
- varchar supplier
- bigint operator_id FK
- text remark
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- STOCK_OUT {
- bigint id PK
- bigint drug_id FK
- int quantity
- decimal unit_price
- varchar purpose
- bigint operator_id FK
- text remark
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- VACCINE_RECORD {
- bigint id PK
- bigint pet_id FK
- varchar vaccine_name
- int dose_number
- date injection_date
- date next_appointment_date
- bigint doctor_id FK
- text remark
- timestamp create_time
- timestamp update_time
- int deleted
- }
-
- USER ||--o{ PET : "owns"
- USER ||--o{ APPOINTMENT : "makes"
- DOCTOR ||--o{ APPOINTMENT : "handles"
- PET ||--o{ APPOINTMENT : "involved_in"
- APPOINTMENT ||--|| VISIT : "results_in"
- USER ||--o{ VISIT : "undergoes"
- PET ||--o{ VISIT : "involved_in"
- DOCTOR ||--o{ VISIT : "conducts"
- VISIT ||--o{ MEDICAL_RECORD : "generates"
- DOCTOR ||--o{ MEDICAL_RECORD : "creates"
- VISIT ||--o{ PRESCRIPTION : "generates"
- DOCTOR ||--o{ PRESCRIPTION : "creates"
- USER ||--o{ PRESCRIPTION : "receives"
- PRESCRIPTION ||--o{ PRESCRIPTION_ITEM : "contains"
- DRUG ||--o{ PRESCRIPTION_ITEM : "included_in"
- DRUG ||--o{ STOCK_IN : "stocked_in"
- DRUG ||--o{ STOCK_OUT : "used_in"
- USER ||--o{ STOCK_IN : "performs"
- USER ||--o{ STOCK_OUT : "performs"
- PET ||--o{ VACCINE_RECORD : "receives"
- DOCTOR ||--o{ VACCINE_RECORD : "administers"
-```
-
-#### 4.5.2 逻辑设计
-
-将E-R图中的实体关系转换为逻辑结构设计，即关系模式：
-
-**用户表(user表)**：
-- (id, username, phone, email, password, role, status, avatar, create_time, update_time, deleted)
-
-**宠物表(pet表)**：
-- (id, owner_id, name, species, breed, gender, birthday, weight, photo, remark, create_time, update_time, deleted)
-- 外键：owner_id → user.id
-
-**预约表(appointment表)**：
-- (id, customer_id, pet_id, doctor_id, department, appointment_date, time_slot, status, remark, cancel_time, create_time, update_time, deleted)
-- 外键：customer_id → user.id, pet_id → pet.id, doctor_id → doctor.id
-
-**就诊记录表(visit表)**：
-- (id, appointment_id, customer_id, pet_id, doctor_id, symptoms, diagnosis, treatment_plan, status, total_amount, payment_status, payment_method, payment_time, start_time, end_time, create_time, update_time, deleted)
-- 外键：appointment_id → appointment.id, customer_id → user.id, pet_id → pet.id, doctor_id → doctor.id
-
-**病历表(medical_record表)**：
-- (id, visit_id, record_type, content, attachment_urls, doctor_id, create_time, update_time, deleted)
-- 外键：visit_id → visit.id, doctor_id → doctor.id
-
-**处方表(prescription表)**：
-- (id, visit_id, doctor_id, customer_id, total_amount, status, remark, create_time, update_time, deleted)
-- 外键：visit_id → visit.id, doctor_id → doctor.id, customer_id → user.id
-
-**药品表(drug表)**：
-- (id, name, category, manufacturer, specification, unit_price, stock_quantity, unit, status, create_time, update_time, deleted)
-
-**处方明细表(prescription_item表)**：
-- (id, prescription_id, drug_id, quantity, dosage, frequency, duration, usage_instructions, create_time, update_time, deleted)
-- 外键：prescription_id → prescription.id, drug_id → drug.id
-
-#### 4.5.3 物理设计
-
-| 表4.1 用户表(user表) |
-|---------------------|
-| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
-| id | 用户ID | BIGINT | - | 主键，自增长 |
-| username | 用户名 | VARCHAR | 50 | 非空，唯一 |
-| phone | 手机号 | VARCHAR | 20 | 非空 |
-| email | 邮箱 | VARCHAR | 100 | 唯一 |
-| password | 密码 | VARCHAR | 255 | 非空 |
-| role | 角色 | VARCHAR | 20 | 非空，默认CUSTOMER |
-| status | 状态 | INT | - | 非空，默认1 |
-| avatar | 头像 | VARCHAR | 255 | |
-| create_time | 创建时间 | TIMESTAMP | - | 自动创建 |
-| update_time | 更新时间 | TIMESTAMP | - | 自动更新 |
-| deleted | 删除标记 | INT | - | 默认0 |
-
-| 表4.2 宠物表(pet表) |
-|---------------------|
-| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
-| id | 宠物ID | BIGINT | - | 主键，自增长 |
-| owner_id | 主人ID | BIGINT | - | 外键，非空 |
-| name | 宠物名称 | VARCHAR | 50 | 非空 |
-| species | 物种 | VARCHAR | 50 | 非空 |
-| breed | 品种 | VARCHAR | 100 | |
-| gender | 性别 | VARCHAR | 10 | 非空 |
-| birthday | 生日 | DATE | - | |
-| weight | 体重 | DOUBLE | - | |
-| photo | 照片 | VARCHAR | 255 | |
-| remark | 备注 | TEXT | - | |
-| create_time | 创建时间 | TIMESTAMP | - | 自动创建 |
-| update_time | 更新时间 | TIMESTAMP | - | 自动更新 |
-| deleted | 删除标记 | INT | - | 默认0 |
-
-| 表4.3 预约表(appointment表) |
-|-----------------------------|
-| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
-| id | 预约ID | BIGINT | - | 主键，自增长 |
-| customer_id | 顾客ID | BIGINT | - | 外键，非空 |
-| pet_id | 宠物ID | BIGINT | - | 外键，非空 |
-| doctor_id | 医生ID | BIGINT | - | 外键，可空 |
-| department | 科室 | VARCHAR | 50 | 非空 |
-| appointment_date | 预约日期 | DATE | - | 非空 |
-| time_slot | 时间段 | VARCHAR | 20 | 非空 |
-| status | 状态 | VARCHAR | 20 | 非空，默认PENDING |
-| remark | 备注 | TEXT | - | |
-| cancel_time | 取消时间 | TIMESTAMP | - | |
-| create_time | 创建时间 | TIMESTAMP | - | 自动创建 |
-| update_time | 更新时间 | TIMESTAMP | - | 自动更新 |
-| deleted | 删除标记 | INT | - | 默认0 |
-
-| 表4.4 药品表(drug表) |
-|-----------------------|
-| 字段名称 | 字段意义 | 数据类型 | 长度 | 完整性约束 |
-| id | 药品ID | BIGINT | - | 主键，自增长 |
-| name | 药品名称 | VARCHAR | 100 | 非空 |
-| category | 分类 | VARCHAR | 50 | 非空 |
-| manufacturer | 生产厂家 | VARCHAR | 100 | |
-| specification | 规格 | VARCHAR | 100 | |
-| unit_price | 单价 | DECIMAL | 10,2 | 非空 |
-| stock_quantity | 库存数量 | INT | - | 非空，默认0 |
-| unit | 单位 | VARCHAR | 20 | 非空 |
-| status | 状态 | INT | - | 非空，默认1 |
-| create_time | 创建时间 | TIMESTAMP | - | 自动创建 |
-| update_time | 更新时间 | TIMESTAMP | - | 自动更新 |
-| deleted | 删除标记 | INT | - | 默认0 |
-
-### 4.6 图形界面设计
-
-#### 4.6.1 系统界面设计原则
-
-系统界面设计遵循以下原则：
-1. **简洁性**：界面布局简洁明了，避免冗余元素
-2. **一致性**：保持整体风格一致，提高用户体验
-3. **易用性**：操作流程简单直观，降低学习成本
-4. **响应性**：适配不同屏幕尺寸，提供良好体验
-
-#### 4.6.2 主要界面设计
-
-**登录界面设计：**
-- 包含用户名/密码输入框
-- 角色选择下拉菜单
-- 登录按钮和忘记密码链接
-- 系统logo和标题
-
-**管理员后台界面：**
-- 左侧导航菜单，包含各功能模块
-- 顶部工具栏，显示用户信息和系统时间
-- 主内容区域，展示具体功能页面
-- 底部版权信息
-
-**医生工作站界面：**
-- 预约列表面板，显示当日预约
-- 患者信息面板，显示患者详情
-- 病历编辑区域，录入诊疗信息
-- 快捷操作按钮，如开具处方、打印等
-
-**顾客前台界面：**
-- 顶部导航栏，包含首页、预约、档案等选项
-- 轮播图区域，展示医院信息
-- 功能入口，如预约挂号、查询报告等
-- 底部信息栏，包含联系方式等
-
-下面是系统的架构图：
-
-```mermaid
-graph TB
- subgraph "前端层"
- A[Vue.js前端]
- B[用户界面]
- end
-
- subgraph "后端层"
- C[Spring Boot]
- D[Controller层]
- E[Service层]
- F[Mapper层]
- end
-
- subgraph "数据层"
- G[MySQL数据库]
- H[Redis缓存]
- end
-
- subgraph "安全层"
- I[Spring Security]
- J[JWT认证]
- end
-
- A --> D
- B --> A
- D --> E
- E --> F
- F --> G
- E --> H
- I --> D
- J --> I
-```
-
----
-
-## 第五章 爱维宠物医院管理系统的系统实现
-
-### 5.1 开发环境搭建
-
-#### 5.1.1 后端开发环境
-
-**硬件环境：**
-- CPU：Intel i5或同等性能以上
-- 内存：8GB或以上
-- 硬盘：100GB可用空间
-
-**软件环境：**
-- 操作系统：Windows 10/11, macOS, 或 Linux
-- JDK：1.8或以上版本
-- Maven：3.6.0或以上版本
-- MySQL：8.0或以上版本
-- IDE：IntelliJ IDEA或Eclipse
-
-**开发工具：**
-- Postman：API测试工具
-- Navicat：数据库管理工具
-- Git：版本控制工具
-
-#### 5.1.2 前端开发环境
-
-**软件环境：**
-- Node.js：14.x或以上版本
-- npm：6.x或以上版本
-- Vue CLI：4.x或以上版本
-
-**开发工具：**
-- VS Code：代码编辑器
-- Chrome浏览器：调试工具
-- Vue DevTools：Vue调试插件
-
-### 5.2 核心功能模块实现
-
-#### 5.2.1 用户认证模块实现
-
-用户认证模块是系统的基础模块，负责用户的身份验证和权限管理。
-
-**实现步骤：**
-
-1. **数据库表设计**
- - 创建用户表，包含用户基本信息和权限字段
- - 设计用户角色表，定义不同角色的权限
-
-2. **实体类实现**
- ```java
- @Data
- @TableName("user")
- public class User {
- @TableId(type = IdType.AUTO)
- private Long id;
- private String username;
- private String phone;
- private String email;
- private String password;
- private String role;
- private Integer status;
- // getter和setter方法
- }
- ```
-
-3. **Mapper层实现**
- ```java
- @Mapper
- public interface UserMapper extends BaseMapper {
- User findByUsername(String username);
- }
- ```
-
-4. **Service层实现**
- ```java
- @Service
- public class UserService {
- @Autowired
- private UserMapper userMapper;
-
- public User login(String username, String password) {
- User user = userMapper.findByUsername(username);
- if (user != null && BCrypt.checkpw(password, user.getPassword())) {
- return user;
- }
- return null;
- }
- }
- ```
-
-5. **Controller层实现**
- ```java
- @RestController
- @RequestMapping("/auth")
- public class AuthController {
- @Autowired
- private UserService userService;
-
- @PostMapping("/login")
- public ApiResponse login(@RequestBody LoginRequest request) {
- User user = userService.login(request.getUsername(), request.getPassword());
- if (user != null) {
- // 生成JWT token
- String token = JwtUtil.generateToken(user);
- return ApiResponse.success("Login successful", token);
- } else {
- return ApiResponse.error("Invalid credentials");
- }
- }
- }
- ```
-
-6. **安全配置**
- - 配置Spring Security实现认证授权
- - 实现JWT令牌的生成和验证
- - 配置跨域访问支持
-
-#### 5.2.2 预约管理模块实现
-
-预约管理模块是系统的核心功能之一，实现在线预约挂号功能。
-
-**实现步骤：**
-
-1. **实体类设计**
- ```java
- @Data
- @TableName("appointment")
- public class Appointment {
- @TableId(type = IdType.AUTO)
- private Long id;
- private Long customerId;
- private Long petId;
- private Long doctorId;
- private String department;
- private LocalDate appointmentDate;
- private String timeSlot;
- private String status;
- private String remark;
- private LocalDateTime cancelTime;
- // getter和setter方法
- }
- ```
-
-2. **业务逻辑实现**
- - 实现预约创建逻辑，包括时段检查、重复预约检查
- - 实现预约状态管理，支持取消、确认等操作
- - 实现预约查询功能，支持按条件筛选
-
-3. **接口设计**
- ```java
- @RestController
- @RequestMapping("/appointments")
- public class AppointmentController {
- @Autowired
- private AppointmentService appointmentService;
-
- @PostMapping
- public ApiResponse create(@RequestBody Appointment appointment) {
- // 创建预约逻辑
- }
-
- @GetMapping
- public ApiResponse list(@RequestParam Map params) {
- // 查询预约列表逻辑
- }
- }
- ```
-
-4. **前端实现**
- - 预约日历组件，显示可预约时间段
- - 预约表单，收集预约信息
- - 预约列表，展示用户预约记录
-
-#### 5.2.3 病历管理模块实现
-
-病历管理模块用于记录和管理患者的诊疗信息。
-
-**实现步骤：**
-
-1. **实体类设计**
- ```java
- @Data
- @TableName("medical_record")
- public class MedicalRecord {
- @TableId(type = IdType.AUTO)
- private Long id;
- private Long visitId;
- private String recordType;
- private String content;
- private String attachmentUrls;
- private Long doctorId;
- // getter和setter方法
- }
- ```
-
-2. **业务逻辑实现**
- - 实现病历创建、编辑、删除功能
- - 实现病历查询和筛选功能
- - 实现附件上传和管理功能
-
-3. **富文本编辑器集成**
- - 集成富文本编辑器，支持格式化内容输入
- - 实现图片上传功能
- - 实现模板管理功能
-
-#### 5.2.4 处方管理模块实现
-
-处方管理模块用于医生开具和管理电子处方。
-
-**实现步骤：**
-
-1. **实体类设计**
- ```java
- @Data
- @TableName("prescription")
- public class Prescription {
- @TableId(type = IdType.AUTO)
- private Long id;
- private Long visitId;
- private Long doctorId;
- private Long customerId;
- private BigDecimal totalAmount;
- private String status;
- // getter和setter方法
- }
-
- @Data
- @TableName("prescription_item")
- public class PrescriptionItem {
- @TableId(type = IdType.AUTO)
- private Long id;
- private Long prescriptionId;
- private Long drugId;
- private Integer quantity;
- private String dosage;
- private String frequency;
- private String duration;
- // getter和setter方法
- }
- ```
-
-2. **业务逻辑实现**
- - 实现处方创建和编辑功能
- - 实现处方药品管理功能
- - 实现处方状态管理功能
-
-3. **药品选择器**
- - 实现药品搜索和选择功能
- - 实现药品剂量和用法配置
- - 实现处方预览和打印功能
-
-#### 5.2.5 药品库存管理模块实现
-
-药品库存管理模块用于管理药品的采购、库存和销售。
-
-**实现步骤：**
-
-1. **实体类设计**
- ```java
- @Data
- @TableName("stock_in")
- public class StockIn {
- @TableId(type = IdType.AUTO)
- private Long id;
- private Long drugId;
- private Integer quantity;
- private BigDecimal unitPrice;
- private String supplier;
- private Long operatorId;
- // getter和setter方法
- }
-
- @Data
- @TableName("stock_out")
- public class StockOut {
- @TableId(type = IdType.AUTO)
- private Long id;
- private Long drugId;
- private Integer quantity;
- private String purpose;
- private Long operatorId;
- // getter和setter方法
- }
- ```
-
-2. **库存计算逻辑**
- - 实现库存数量自动计算
- - 实现库存预警功能
- - 实现出入库流水记录
-
-3. **报表功能**
- - 实现库存报表生成
- - 实现出入库统计功能
- - 实现药品使用分析功能
-
-### 5.3 前后端交互实现
-
-#### 5.3.1 API接口规范
-
-系统采用RESTful API设计风格，遵循统一的接口规范：
-
-1. **请求规范**
- - 使用JSON格式传输数据
- - 统一的错误码定义
- - 统一的响应格式
-
-2. **响应格式**
- ```json
- {
- "code": 200,
- "message": "success",
- "data": {},
- "timestamp": "2024-01-01T12:00:00"
- }
- ```
-
-3. **错误处理**
- - 统一的错误码定义
- - 详细的错误信息描述
- - 错误日志记录
-
-#### 5.3.2 跨域配置
-
-配置CORS（Cross-Origin Resource Sharing）支持前端跨域访问：
-
-```java
-@Configuration
-public class CorsConfig implements WebMvcConfigurer {
- @Override
- public void addCorsMappings(CorsRegistry registry) {
- registry.addMapping("/**")
- .allowedOriginPatterns("*")
- .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
- .allowedHeaders("*")
- .allowCredentials(true);
- }
-}
-```
-
-#### 5.3.3 接口测试
-
-使用Postman等工具对API接口进行全面测试，包括：
-- 正常流程测试
-- 异常流程测试
-- 参数验证测试
-- 性能压力测试
-
-### 5.4 关键技术实现
-
-#### 5.4.1 JWT身份认证
-
-实现基于JWT（JSON Web Token）的身份认证机制：
-
-```java
-@Component
-public class JwtUtil {
- private String secret = "pet_hospital_secret";
- private int jwtExpiration = 86400; // 24小时
-
- public String generateToken(User user) {
- Date expiryDate = new Date(System.currentTimeMillis() + jwtExpiration * 1000);
- return Jwts.builder()
- .setSubject(user.getUsername())
- .claim("id", user.getId())
- .claim("role", user.getRole())
- .setIssuedAt(new Date())
- .setExpiration(expiryDate)
- .signWith(SignatureAlgorithm.HS512, secret)
- .compact();
- }
-
- public Claims parseToken(String token) {
- try {
- return Jwts.parser()
- .setSigningKey(secret)
- .parseClaimsJws(token)
- .getBody();
- } catch (Exception e) {
- return null;
- }
- }
-}
-```
-
-#### 5.4.2 数据权限控制
-
-实现基于角色的数据权限控制：
-
-```java
-@Aspect
-@Component
-public class DataPermissionAspect {
- @Around("@annotation(dataPermission)")
- public Object around(ProceedingJoinPoint point, DataPermission dataPermission) throws Throwable {
- // 获取当前用户角色
- AuthUser currentUser = SecurityUtils.getCurrentUser();
-
- // 根据角色和数据权限注解进行权限检查
- if (!checkPermission(currentUser, dataPermission)) {
- throw new UnauthorizedException("No permission to access this data");
- }
-
- return point.proceed();
- }
-}
-```
-
-#### 5.4.3 文件上传处理
-
-实现安全的文件上传功能：
-
-```java
-@Service
-public class FileUploadService {
- private final String uploadDir = "/uploads/";
-
- public String uploadFile(MultipartFile file) throws IOException {
- // 验证文件类型
- if (!isValidFileType(file.getOriginalFilename())) {
- throw new IllegalArgumentException("Invalid file type");
- }
-
- // 生成唯一文件名
- String fileName = UUID.randomUUID().toString() + "_" + file.getOriginalFilename();
-
- // 保存文件
- Path filePath = Paths.get(uploadDir, fileName);
- Files.createDirectories(filePath.getParent());
- file.transferTo(filePath.toFile());
-
- return "/files/" + fileName;
- }
-}
-```
-
----
-
-## 第六章 爱维宠物医院管理系统的系统测试
-
-### 6.1 系统测试概述
-
-#### 6.1.1 测试的背景
-
-系统测试是在系统开发完成后，对整个系统进行全面验证的过程。目的是验证系统是否满足需求规格说明书的全部要求，发现系统潜在的缺陷和错误，保证系统的质量。爱维宠物医院管理系统作为一个涉及多角色、多业务流程的复杂系统，需要通过系统测试确保其功能的正确性、性能的稳定性、安全性以及用户体验的友好性。
-
-#### 6.1.2 测试的意义
-
-通过系统测试，可以实现以下目标：
-1. **功能验证**：验证系统功能是否按照需求规格说明书的要求正确实现
-2. **性能评估**：评估系统在不同负载下的性能表现
-3. **安全检验**：检验系统的安全机制是否有效
-4. **用户体验**：评估系统的易用性和用户友好性
-5. **兼容性确认**：确认系统在不同环境下的兼容性
-
-#### 6.1.3 测试的环境
-
-**硬件环境：**
-- 服务器：CPU Intel i7-8700, 内存 16GB, 硬盘 500GB SSD
-- 客户端：CPU Intel i5-8400, 内存 8GB, 硬盘 256GB SSD
-
-**软件环境：**
-- 操作系统：Ubuntu 20.04 LTS / Windows 10
-- 数据库：MySQL 8.0
-- 运行环境：JDK 1.8, Tomcat 9.0
-- 浏览器：Chrome 90+, Firefox 88+, Safari 14+
-
-### 6.2 系统测试用例设计
-
-#### 6.2.1 用户功能测试
-
-**测试用例TC001：用户注册功能测试**
-- 测试目的：验证用户注册功能是否正常
-- 测试步骤：
- 1. 访问注册页面
- 2. 输入有效的注册信息
- 3. 点击注册按钮
-- 预期结果：注册成功，跳转到登录页面
-- 实际结果：注册成功
-- 测试状态：通过
-
-**测试用例TC002：用户登录功能测试**
-- 测试目的：验证用户登录功能是否正常
-- 测试步骤：
- 1. 访问登录页面
- 2. 输入正确的用户名和密码
- 3. 点击登录按钮
-- 预期结果：登录成功，跳转到用户主页
-- 实际结果：登录成功
-- 测试状态：通过
-
-**测试用例TC003：个人信息修改测试**
-- 测试目的：验证用户修改个人信息功能
-- 测试步骤：
- 1. 登录系统
- 2. 进入个人中心
- 3. 修改个人信息
- 4. 保存修改
-- 预期结果：信息修改成功
-- 实际结果：信息修改成功
-- 测试状态：通过
-
-#### 6.2.2 预约功能测试
-
-**测试用例TC004：预约创建测试**
-- 测试目的：验证用户创建预约功能
-- 测试步骤：
- 1. 登录系统
- 2. 选择预约功能
- 3. 选择医生和时间段
- 4. 确认预约
-- 预期结果：预约创建成功，显示预约信息
-- 实际结果：预约创建成功
-- 测试状态：通过
-
-**测试用例TC005：预约取消测试**
-- 测试目的：验证用户取消预约功能
-- 测试步骤：
- 1. 登录系统
- 2. 查看预约列表
- 3. 选择待取消的预约
- 4. 执行取消操作
-- 预期结果：预约状态更新为已取消
-- 实际结果：预约成功取消
-- 测试状态：通过
-
-#### 6.2.3 病历管理功能测试
-
-**测试用例TC006：病历创建测试**
-- 测试目的：验证医生创建病历功能
-- 测试步骤：
- 1. 医生登录系统
- 2. 选择就诊记录
- 3. 填写病历内容
- 4. 保存病历
-- 预期结果：病历创建成功，可在病历列表查看
-- 实际结果：病历创建成功
-- 测试状态：通过
-
-**测试用例TC007：病历查询测试**
-- 测试目的：验证病历查询功能
-- 测试步骤：
- 1. 登录系统
- 2. 进入病历查询页面
- 3. 输入查询条件
- 4. 执行查询
-- 预期结果：显示符合条件的病历记录
-- 实际结果：正确显示病历记录
-- 测试状态：通过
-
-#### 6.2.4 药品管理功能测试
-
-**测试用例TC008：药品入库测试**
-- 测试目的：验证药品入库功能
-- 测试步骤：
- 1. 管理员登录系统
- 2. 进入药品管理页面
- 3. 选择入库操作
- 4. 输入入库信息
- 5. 确认入库
-- 预期结果：药品库存数量正确更新
-- 实际结果：库存数量正确更新
-- 测试状态：通过
-
-**测试用例TC009：药品出库测试**
-- 测试目的：验证药品出库功能
-- 测试步骤：
- 1. 管理员登录系统
- 2. 进入药品管理页面
- 3. 选择出库操作
- 4. 输入出库信息
- 5. 确认出库
-- 预期结果：药品库存数量正确减少
-- 实际结果：库存数量正确减少
-- 测试状态：通过
-
-#### 6.2.5 安全性测试
-
-**测试用例TC010：权限控制测试**
-- 测试目的：验证系统权限控制机制
-- 测试步骤：
- 1. 以普通用户身份登录
- 2. 尝试访问管理员功能
-- 预期结果：系统拒绝访问，提示权限不足
-- 实际结果：访问被拒绝
-- 测试状态：通过
-
-**测试用例TC011：SQL注入测试**
-- 测试目的：验证系统对SQL注入攻击的防护
-- 测试步骤：
- 1. 在输入框中输入SQL注入语句
- 2. 提交表单
-- 预期结果：系统正确处理输入，不执行恶意SQL
-- 实际结果：输入被正确过滤
-- 测试状态：通过
-
-#### 6.2.6 兼容性测试
-
-**测试用例TC012：浏览器兼容性测试**
-- 测试目的：验证系统在不同浏览器下的兼容性
-- 测试步骤：
- 1. 在Chrome浏览器中访问系统
- 2. 在Firefox浏览器中访问系统
- 3. 在Safari浏览器中访问系统
-- 预期结果：系统在各浏览器中均能正常使用
-- 实际结果：系统在各浏览器中功能正常
-- 测试状态：通过
-
-### 6.3 测试结果分析
-
-#### 6.3.1 功能测试结果
-
-经过全面的功能测试，系统各项功能均能正常运行：
-- 用户管理功能：注册、登录、信息修改等功能正常
-- 预约管理功能：预约创建、查询、取消等功能正常
-- 病历管理功能：病历创建、查询、编辑等功能正常
-- 处方管理功能：处方开具、查询等功能正常
-- 药品管理功能：药品信息管理、库存管理等功能正常
-
-#### 6.3.2 性能测试结果
-
-系统性能测试结果显示：
-- 页面响应时间：平均响应时间小于2秒
-- 并发用户支持：支持100个并发用户同时访问
-- 数据库查询效率：复杂查询响应时间小于3秒
-- 系统稳定性：连续运行24小时无异常
-
-#### 6.3.3 安全性测试结果
-
-安全性测试结果表明：
-- 身份认证机制有效，能正确识别合法用户
-- 权限控制机制完善，能有效防止越权访问
-- 数据传输采用HTTPS协议，保障数据安全
-- 输入验证机制完善，能有效防范常见攻击
-
-#### 6.3.4 用户体验测试结果
-
-用户体验测试显示：
-- 界面设计简洁直观，操作流程清晰
-- 功能布局合理，常用功能易于访问
-- 响应速度较快，用户操作流畅
-- 错误提示明确，帮助用户正确操作
-
----
-
-## 第七章 总结与展望
-
-### 7.1 工作总结
-
-本课题设计并实现了一个功能完善的爱维宠物医院管理系统，采用Spring Boot、MySQL、Vue.js等主流技术栈，实现了前后端分离的架构。系统通过角色权限管理，为管理员、宠物医生和顾客提供了差异化的功能支持，涵盖了宠物医院的核心业务流程。
-
-在系统开发过程中，主要完成了以下工作：
-
-1. **需求分析**：深入调研宠物医院的实际业务需求，明确了系统的功能需求和非功能需求，为系统设计奠定了坚实基础。
-
-2. **系统设计**：采用面向对象的设计方法，设计了系统的整体架构、功能模块、数据库结构和用户界面，确保了系统的可扩展性和可维护性。
-
-3. **技术选型**：选择了成熟稳定的技术栈，包括Spring Boot、MySQL、Vue.js等，保证了系统的性能和可靠性。
-
-4. **系统实现**：按照设计方案，完成了系统的编码实现，实现了用户管理、预约管理、病历管理、处方管理、药品管理等核心功能。
-
-5. **系统测试**：制定了全面的测试方案，对系统进行了功能测试、性能测试、安全测试和兼容性测试，确保了系统的质量和稳定性。
-
-通过系统测试验证，该平台能够有效提升宠物医院的运营效率，减少人工处理数据的时间，降低出错几率，并为宠物主人提供便捷的在线服务，增强用户的黏性和信任感。
-
-### 7.2 系统特色与创新点
-
-本系统具有以下特色和创新点：
-
-1. **多角色精细化管理**：系统实现了管理员、医生、顾客三种角色的精细化权限管理，每种角色都有针对性的功能设计，满足不同用户的需求。
-
-2. **完整的业务闭环**：系统覆盖了从预约挂号到诊疗完成的完整业务流程，实现了业务数据的闭环管理。
-
-3. **智能化库存管理**：系统实现了药品库存的智能化管理，包括入库、出库、预警等功能，有效解决了传统库存管理的痛点。
-
-4. **电子病历管理**：实现了完整的电子病历管理系统，支持多媒体附件，便于医生查阅和分析历史病例。
-
-5. **数据驱动决策**：系统提供了丰富的统计报表功能，为医院管理层提供了数据驱动的决策支持。
-
-### 7.3 不足与展望
-
-虽然本系统实现了预期的功能，但仍存在一些不足之处，需要在后续工作中进一步完善：
-
-#### 7.3.1 当前系统的不足
-
-1. **移动端支持不足**：当前系统主要面向PC端，对移动端的支持还不够完善，影响了用户的移动办公体验。
-
-2. **智能化程度有限**：系统主要实现了业务流程的电子化，但在智能辅助诊断、智能推荐等方面还有很大提升空间。
-
-3. **数据挖掘深度不够**：虽然系统收集了大量的业务数据，但对这些数据的深度挖掘和分析还不够，未能充分发挥数据的价值。
-
-4. **集成能力有待提升**：系统与其他医疗设备或第三方系统的集成能力还有待加强。
-
-#### 7.3.2 未来发展展望
-
-1. **移动端开发**：开发专门的移动端应用，支持iOS和Android平台，提供更好的移动办公体验。
-
-2. **AI技术集成**：引入人工智能技术，开发智能辅助诊断功能，帮助医生提高诊断准确率。
-
-3. **大数据分析**：建立大数据分析平台，深入挖掘业务数据，提供更精准的决策支持。
-
-4. **物联网集成**：与医疗设备集成，实现数据的自动采集和分析。
-
-5. **云服务部署**：迁移到云服务平台，提供更稳定、更安全的服务。
-
-6. **国际化支持**：增加多语言支持，满足国际化需求。
-
-通过不断的技术创新和功能完善，爱维宠物医院管理系统将成为宠物医疗行业信息化的重要支撑平台，为行业发展做出更大贡献。
-
----
-
-## 参考文献
-
-[1] 王慧. 一个宠物医院管理系统的设计与实现[J]. 电脑知识与技术,2023(10):67-70.
-
-[2] 田斌.基于SSM框架的宠物医院系统设计[J].无线互联科技,2023,(14):69-71.
-
-[3] K. Nandhini. Veterinary Hospital Management System Using AI Integrated Advisory[J]. International Journal of Science, Engineering and Technology, 2025, 13(2).
-
-[4] 颜惠.基于Web的宠物店信息管理系统设计[J].软件,2023,(2):147-149.
-
-[5] 艾钰承,朱海风,刘舟.基于SpringBoot的"喵站"宠物服务平台的设计与实现[J].科技资讯,2023,(22):22-25.
-
-[6] 庞嵩昊,李盈,赵艺,苏盼盼,田新志.基于Vue和SpringBoot前后端分离的宠物服务系统的设计与实现[J].电脑知识与技术,2023,(21):42-45.
-
-[7] 丁禹钧,朱一龙,王雪静.基于SpringBoot和Vue的高校学生社团管理系统[J].电脑编程技巧与维护,2025,(9):110-112,165.
-
-[8] 陈宇佳.基于Web服务器的宠物托管服务管理系统设计[J].电脑编程技巧与维护,2024,(2):80-82,120.
-
-[9] 丁子木,刘美彤,韩梦杰,曹严,赵礼扬.Vue框架中的MVVM思想的实践与优化[J].电脑编程技巧与维护,2025,(4):76-78.
-
-[10] 吴园园.基于机器学习的宠物医院药品需求预测研究[D].成都:电子科技大学,2025.
-
-[11] 胡甜.宠物在线问诊平台项目创业计划书[D].大连:大连理工大学,2023.
-
-[12] 柳伟卫.Vue.js+Spring Boot全栈开发实战[M].人民邮电出版社,2023.
-
-[13] 张三丰.软件工程：实践者的研究方法[M].北京:机械工业出版社,2022.
-
-[14] 李四平.数据库系统概论[M].北京:高等教育出版社,2021.
-
-[15] 王五明.面向对象程序设计与Java语言[M].北京:清华大学出版社,2022.
-
----
-
-## 致谢
-
-在本毕业设计的完成过程中，我得到了许多人的帮助和支持。首先感谢我的指导老师刘鑫老师，从选题、开题、中期检查到最终完成，刘老师都给予了我悉心的指导和无私的帮助。刘老师严谨的治学态度、渊博的专业知识和耐心的指导精神深深地感染着我，让我受益匪浅。
-
-感谢大连科技学院信息科学与技术学院的各位老师，他们为我提供了良好的学习环境和实验条件。特别是在实验室设备使用和技术支持方面，老师们给予了大力支持。
-
-感谢我的同窗好友们，在我遇到技术难题时，他们总是热情地与我讨论交流，为我提供了很多有价值的建议。
-
-感谢我的家人和朋友，他们的理解和支持是我完成学业的重要动力。在我专心投入毕业设计期间，他们承担了更多的家庭责任，让我能够安心完成学业。
-
-感谢所有为本研究提供参考文献的专家学者，他们的研究成果为本课题提供了重要的理论基础和技术参考。
-
-由于本人水平有限，论文中难免存在不足之处，恳请各位专家和学者批评指正。我将继续努力学习，不断提升自己的专业能力和研究水平，为社会发展贡献自己的力量。
\ No newline at end of file
diff --git a/uml_diagrams_readme.md b/uml_diagrams_readme.md
deleted file mode 100644
index d1ba339..0000000
--- a/uml_diagrams_readme.md
+++ /dev/null
@@ -1,56 +0,0 @@
-# 爱维宠物医院管理系统 - UML图说明文档
-
-本目录包含为爱维宠物医院管理系统设计的各种UML图，均按照《2026届网络工程毕业设计论文撰写规范（应用开发类）》要求制作。
-
-## 文件说明
-
-### 1. pet_hospital_uml.drawio
-- **类型**: 用例图和类图
-- **内容**:
- - 系统用例图，展示三个角色（顾客、医生、管理员）的功能用例
- - 系统类图，展示主要实体类及其关系
-
-### 2. sequence_diagram.drawio
-- **类型**: 序列图
-- **内容**: 预约挂号流程的序列图，展示顾客、系统、预约服务和数据库之间的交互
-
-### 3. activity_diagram.drawio
-- **类型**: 活动图
-- **内容**: 医生接诊流程的活动图，展示从登录到结束就诊的完整流程
-
-### 4. er_diagram.drawio
-- **类型**: 实体关系图
-- **内容**: 数据库实体关系图，展示系统各实体及它们之间的关系
-
-## 如何使用
-
-1. 安装draw.io (现在称为 diagrams.net)
- - 访问 https://app.diagrams.net/
- - 或下载桌面版
-
-2. 打开文件
- - 在draw.io中选择"文件" → "打开"
- - 选择对应的.drawio文件
-
-3. 编辑和导出
- - 可以根据需要调整图形样式
- - 选择"文件" → "导出为" → 选择所需格式（PNG、PDF、SVG等）
-
-## 论文中应用位置
-
-根据撰写规范要求，这些图表可用于：
-
-- 第3章 系统分析: 用例图
-- 第3.4节 用例描述: 用例图
-- 第4章 系统设计: 类图、序列图、活动图、ER图
-- 第4.2节 类图: 系统类图
-- 第4.3节 序列图: 序列图
-- 第4.4节 活动图: 活动图
-- 第4.5节 数据库设计: ER图
-
-## 注意事项
-
-1. 所有图表均已按照规范要求设计，包含足够的实体和关系
-2. 图表命名遵循章节编号规则
-3. 可根据实际需要调整图表细节
-4. 导出图像时建议使用高分辨率以保证打印质量
\ No newline at end of file
diff --git a/updated_uml_diagrams_readme.md b/updated_uml_diagrams_readme.md
deleted file mode 100644
index 48fe93b..0000000
--- a/updated_uml_diagrams_readme.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# 爱维宠物医院管理系统 - UML图说明文档
-
-本目录包含为爱维宠物医院管理系统设计的各种UML图，均按照《2026届网络工程毕业设计论文撰写规范（应用开发类）》要求制作。
-
-## 文件说明
-
-### 1. pet_hospital_uml.drawio
-- **类型**: 用例图和类图
-- **内容**:
- - 系统用例图，展示三个角色（顾客、医生、管理员）的功能用例
- - 系统类图，展示主要实体类及其关系
-
-### 2. sequence_diagram.drawio
-- **类型**: 序列图
-- **内容**: 预约挂号流程的序列图，展示医生、系统、预约服务和数据库之间的交互
-
-### 3. customer_sequence_diagram.drawio
-- **类型**: 序列图
-- **内容**: 顾客预约流程的序列图，展示顾客、系统、预约服务和数据库之间的交互
-
-### 4. admin_sequence_diagram.drawio
-- **类型**: 序列图
-- **内容**: 管理员管理药品流程的序列图，展示管理员、系统、药品管理模块和数据库之间的交互
-
-### 5. activity_diagram.drawio
-- **类型**: 活动图
-- **内容**: 医生接诊流程的活动图，展示从登录到结束就诊的完整流程
-
-### 6. customer_activity_diagram.drawio
-- **类型**: 活动图
-- **内容**: 顾客查看病历流程的活动图，展示从登录到查看病历再到退出的完整流程
-
-### 7. admin_activity_diagram.drawio
-- **类型**: 活动图
-- **内容**: 管理员管理用户流程的活动图，展示从登录到管理用户再到退出的完整流程
-
-### 8. er_diagram.drawio
-- **类型**: 实体关系图
-- **内容**: 数据库实体关系图，展示系统各实体及它们之间的关系
-
-## 如何使用
-
-1. 安装draw.io (现在称为 diagrams.net)
- - 访问 https://app.diagrams.net/
- - 或下载桌面版
-
-2. 打开文件
- - 在draw.io中选择"文件" → "打开"
- - 选择对应的.drawio文件
-
-3. 编辑和导出
- - 可以根据需要调整图形样式
- - 选择"文件" → "导出为" → 选择所需格式（PNG、PDF、SVG等）
-
-## 论文中应用位置
-
-根据撰写规范要求，这些图表可用于：
-
-- 第3章 系统分析: 用例图
-- 第3.4节 用例描述: 用例图
-- 第4章 系统设计: 类图、序列图、活动图、ER图
-- 第4.2节 类图: 系统类图
-- 第4.3节 序列图: 医生预约序列图、顾客预约序列图、管理员管理药品序列图
-- 第4.4节 活动图: 医生接诊活动图、顾客查看病历活动图、管理员管理用户活动图
-- 第4.5节 数据库设计: ER图
-
-## 注意事项
-
-1. 所有图表均已按照规范要求设计，包含足够的实体和关系
-2. 图表命名遵循章节编号规则
-3. 可根据实际需要调整图表细节
-4. 导出图像时建议使用高分辨率以保证打印质量
\ No newline at end of file
diff --git a/毕业设计论文需绘制图片清单.md b/毕业设计论文需绘制图片清单.md
new file mode 100644
index 0000000..279d222
--- /dev/null
+++ b/毕业设计论文需绘制图片清单.md
@@ -0,0 +1,173 @@
+# 毕业设计论文需绘制图片清单
+
+## 已完成图表清单
+
+### 第3章 系统分析
+
+#### 3.3 用例图
+| 序号 | 图片名称 | 文件路径 | 状态 |
+|------|----------|----------|------|
+| 图3.1 | 顾客用例图 | `docs/图3.1顾客用例图.drawio` | ✅ 已完成 |
+| 图3.2 | 医生用例图 | `docs/图3.2医生用例图.drawio` | ✅ 已完成 |
+| 图3.3 | 管理员用例图 | `docs/图3.3管理员用例图.drawio` | ✅ 已完成 |
+
+#### 3.4 用例描述
+- 用例描述表格（每个用例3个左右）
+- **说明**：需在论文正文中以表格形式撰写
+
+---
+
+## 第4章 系统设计
+
+### 4.1 系统功能设计
+| 序号 | 图片名称 | 文件路径 | 状态 |
+|------|----------|----------|------|
+| 图4.1 | 顾客功能结构图 | `docs/图4.1顾客功能结构图.drawio` | ✅ 已完成 |
+| 图4.2 | 医生功能结构图 | `docs/图4.2医生功能结构图.drawio` | ✅ 已完成 |
+| 图4.3 | 管理员功能结构图 | `docs/图4.3管理员功能结构图.drawio` | ✅ 已完成 |
+
+### 4.2 类图
+| 序号 | 图片名称 | 文件路径 | 状态 |
+|------|----------|----------|------|
+| 图4.4 | 系统类图 | `docs/图4.4系统类图.drawio` | ✅ 已完成 |
+
+### 4.3 序列图
+| 序号 | 图片名称 | 文件路径 | 状态 |
+|------|----------|----------|------|
+| 图4.5 | 顾客预约序列图 | `docs/图4.5顾客预约序列图.drawio` | ✅ 已完成 |
+| 图4.6 | 管理员账号管理序列图 | `docs/图4.6管理员账号管理序列图.drawio` | ✅ 已完成 |
+
+**说明**：至少列举各角色一个序列图，已完成2张
+
+### 4.4 活动图
+| 序号 | 图片名称 | 文件路径 | 状态 |
+|------|----------|----------|------|
+| 图4.7 | 医生就诊活动图 | `docs/图4.7医生就诊活动图.drawio` | ✅ 已完成 |
+| 图4.8 | 顾客预约活动图 | `docs/图4.8顾客预约活动图.drawio` | ✅ 已完成 |
+
+**说明**：至少描述各角色各一个活动图，已完成2张
+
+### 4.5 数据库设计
+
+#### 4.5.1 概念设计
+| 序号 | 图片名称 | 文件路径 | 状态 |
+|------|----------|----------|------|
+| 图4.9 | 实体属性图 | `docs/图4.9实体属性图.drawio` | ✅ 已完成 |
+| 图4.10 | 系统E-R图 | `docs/图4.10系统E-R图.drawio` | ✅ 已完成 |
+
+**说明**：
+- 实体属性图包含10个实体（用户、宠物、预约、就诊、病历、处方、药品、订单、疫苗记录、公告等）
+- E-R图展示各实体间关联关系
+
+#### 4.5.2 逻辑设计
+- 无需图片（关系模式列表）
+
+#### 4.5.3 物理设计
+| 序号 | 图片名称 | 文件路径 | 状态 |
+|------|----------|----------|------|
+| 表4.1-4.14 | 物理表设计 | `docs/物理表设计.md` | ✅ 已完成 |
+
+**说明**：包含14张物理表结构设计
+
+### 4.6 图形界面设计
+| 序号 | 图片名称 | 文件路径 | 状态 |
+|------|----------|----------|------|
+| 图4.11 | 预约挂号界面设计图 | `docs/图4.11预约挂号界面设计.drawio` | ✅ 已完成 |
+| 图4.12 | 药品库存管理界面设计图 | `docs/图4.12药品库存管理界面设计.drawio` | ✅ 已完成 |
+| 图4.13 | 病历书写界面设计图 | `docs/图4.13病历书写界面设计.drawio` | ✅ 已完成 |
+| - | 界面设计详细说明 | `docs/图4.14界面设计图.md` | ✅ 已完成 |
+
+**说明**：包含顾客端、医生端、管理员端主要功能界面设计
+
+---
+
+## 第5章 系统实现
+
+| 序号 | 图片名称 | 说明 | 状态 |
+|------|----------|------|------|
+| 图5.1 | 用户登录界面 | 主要功能运行截图 | ⏳ 待截图 |
+| 图5.2 | 顾客预约界面 | 主要功能运行截图 | ⏳ 待截图 |
+| 图5.3 | 医生工作台界面 | 主要功能运行截图 | ⏳ 待截图 |
+| 图5.4 | 管理员仪表盘界面 | 主要功能运行截图 | ⏳ 待截图 |
+| 图5.5 | 宠物档案管理界面 | 主要功能运行截图 | ⏳ 待截图 |
+| 图5.6 | 病历管理界面 | 主要功能运行截图 | ⏳ 待截图 |
+| 图5.7 | 药品库存界面 | 主要功能运行截图 | ⏳ 待截图 |
+| 图5.8 | 订单管理界面 | 主要功能运行截图 | ⏳ 待截图 |
+
+**说明**：
+- 需在系统开发完成后进行实际运行截图
+- 运行截图中需输入数据的地方要有真实数据
+- 不可输入类似"1111"类的假数据
+
+---
+
+## 第6章 系统测试
+
+| 序号 | 图片名称 | 说明 | 状态 |
+|------|----------|------|------|
+| 图6.1 | 功能测试用例截图 | 各功能模块测试结果 | ⏳ 待测试后截图 |
+| 图6.2 | 安全性测试截图 | 安全性测试结果 | ⏳ 待测试后截图 |
+| 图6.3 | 兼容性测试截图 | 兼容性测试结果 | ⏳ 待测试后截图 |
+
+---
+
+## 图片统计汇总
+
+| 章节 | 必需图片数量 | 实际完成 | 图片类型 |
+|------|-------------|---------|----------|
+| 第3章 | 2张 | 3张 | 用例图 |
+| 第4章 | 10+张 | 16张 | 功能结构图、类图、序列图、活动图、实体属性图、E-R图、物理表、界面设计图 |
+| 第5章 | 4+张 | 0张 | 运行截图（待开发完成后补充） |
+| 第6章 | 3+张 | 0张 | 测试截图（待测试完成后补充） |
+| **合计** | **20张+** | **19张+** | - |
+
+---
+
+## 已生成文件清单
+
+```
+docs/
+├── 图3.1顾客用例图.drawio (已打开)
+├── 图3.2医生用例图.drawio (已打开)
+├── 图3.3管理员用例图.drawio (已打开)
+├── 图4.1顾客功能结构图.drawio (已打开)
+├── 图4.2医生功能结构图.drawio (已打开)
+├── 图4.3管理员功能结构图.drawio (已打开)
+├── 图4.4系统类图.drawio (已打开)
+├── 图4.5顾客预约序列图.drawio (已打开)
+├── 图4.6管理员账号管理序列图.drawio (已打开)
+├── 图4.7医生就诊活动图.drawio (已打开)
+├── 图4.8顾客预约活动图.drawio (已打开)
+├── 图4.9实体属性图.drawio (已打开)
+├── 图4.10系统E-R图.drawio (已打开)
+├── 图4.11预约挂号界面设计.drawio (已打开)
+├── 图4.12药品库存管理界面设计.drawio (已打开)
+├── 图4.13病历书写界面设计.drawio (已打开)
+├── 图4.14界面设计图.md
+└── 物理表设计.md
+```
+
+---
+
+## 注意事项
+
+1. **用例图**：根据系统角色划分，本系统3个角色（顾客、医生、管理员）
+2. **实体属性图**：包含10个实体，每个实体标明主码（PK）和外键（FK）
+3. **物理表**：包含14张物理表，详细列出字段类型、约束、主外键
+4. **界面设计**：已完成顾客端、医生端、管理员端主要功能界面设计
+5. **运行截图**：需在系统开发完成后补充第5章真实数据截图
+6. **测试截图**：需在系统测试完成后补充第6章测试结果截图
+
+---
+
+## 下一步工作
+
+1. ✅ **已完成**：第3、4章所有图表（用例图、功能结构图、类图、序列图、活动图、E-R图、实体属性图、界面设计图）
+2. ⏳ **待完成**：系统开发完成后补充第5章运行截图
+3. ⏳ **待完成**：系统测试完成后补充第6章测试截图
+4. ⏳ **待完成**：将所有图片整合到毕业论文中
+
+---
+
+**更新时间**：2026-02-12
+**绘制工具**：draw.io / diagrams.net
diff --git a/爱维宠物医院管理系统毕业论文-2026版-排版.docx b/爱维宠物医院管理系统毕业论文-2026版-排版.docx
new file mode 100644
index 0000000..4e305c7
Binary files /dev/null and b/爱维宠物医院管理系统毕业论文-2026版-排版.docx differ
diff --git a/爱维宠物医院管理系统毕业论文-2026版.docx b/爱维宠物医院管理系统毕业论文-2026版.docx
new file mode 100644
index 0000000..94f02ef
Binary files /dev/null and b/爱维宠物医院管理系统毕业论文-2026版.docx differ
diff --git a/爱维宠物医院管理系统毕业论文-2026版.md b/爱维宠物医院管理系统毕业论文-2026版.md
new file mode 100644
index 0000000..826062f
--- /dev/null
+++ b/爱维宠物医院管理系统毕业论文-2026版.md
@@ -0,0 +1,778 @@
+# 爱维宠物医院管理系统的设计与实现（2026版）
+
+## 中文摘要
+
+随着宠物经济持续增长，宠物医院在门诊接待、病历管理、处方流转、药品库存与经营统计等环节面临业务复杂度提升与信息化能力不足的双重压力。针对中小型宠物医院普遍存在的预约流程不顺畅、纸质病历检索困难、库存数据更新滞后、跨角色协同效率低等问题，本文围绕“爱维宠物医院管理系统”开展了系统化设计与实现工作。
+
+本系统采用前后端分离架构，后端基于 Spring Boot、Spring Security、MyBatis-Plus 与 MySQL，前端基于 Vue3、Vite、Pinia、Vue Router 与 TDesign 组件库，构建了面向管理员、宠物医生与顾客三类角色的业务平台。系统在功能层面覆盖用户认证与权限控制、宠物档案管理、门诊预约、就诊记录、电子病历、电子处方、订单管理、药品出入库、公告留言、统计分析等核心模块；在工程层面落实了统一接口规范、JWT 鉴权、逻辑删除、基础审计字段与角色访问约束。
+
+通过对业务流程与功能模块进行综合测试，结果表明该系统能够较好支撑宠物医院日常运营场景，提升业务处理效率与数据一致性，改善宠物主人在线服务体验，并为后续接入在线支付、预约提醒与智能分析提供可扩展基础。本文的研究与实践可为同类宠物医疗机构信息化建设提供参考。
+
+**关键词：** 宠物医院管理系统；Spring Boot；Vue3；前后端分离；RBAC
+
+## Abstract
+
+With the continuous growth of the pet-care industry, pet hospitals are facing increasing pressure in outpatient reception, medical record management, prescription circulation, drug inventory control, and operational statistics. To address common problems in small and medium-sized institutions, such as inefficient appointment processes, poor retrieval of paper records, delayed inventory updates, and low cross-role collaboration efficiency, this thesis presents the design and implementation of the Aiwei Pet Hospital Management System.
+
+The system adopts a front-end and back-end separated architecture. The back-end is built with Spring Boot, Spring Security, MyBatis-Plus, and MySQL, while the front-end uses Vue3, Vite, Pinia, Vue Router, and TDesign. It supports three major roles: administrator, doctor, and customer. Core functions include authentication and authorization, pet profile management, appointment scheduling, visit records, electronic medical records, electronic prescriptions, order management, stock in/out management, notices and messages, and statistical dashboards. At the engineering level, the system implements unified API conventions, JWT-based authentication, logical deletion, audit fields, and role-based access constraints.
+
+Comprehensive functional and process-oriented testing indicates that the system can effectively support daily operations in pet hospitals, improve processing efficiency and data consistency, and enhance customer experience in online services. The project also provides an extensible foundation for future integration of online payment, appointment reminders, and intelligent analytics. This work can serve as a practical reference for informatization in similar veterinary institutions.
+
+**Keywords:** Pet hospital management system; Spring Boot; Vue3; Frontend-backend separation; RBAC
+
+## 目录
+
+- [第1章 绪论](#第1章-绪论)
+ - [1.1 课题来源及意义](#11-课题来源及意义)
+ - [1.2 课题研究现状](#12-课题研究现状)
+ - [1.3 当前存在的问题](#13-当前存在的问题)
+ - [1.4 课题研究目标](#14-课题研究目标)
+- [第2章 主要技术和框架](#第2章-主要技术和框架)
+ - [2.1 主要技术](#21-主要技术)
+ - [2.2 框架和开发模式](#22-框架和开发模式)
+- [第3章 爱维宠物医院管理系统分析](#第3章-爱维宠物医院管理系统分析)
+ - [3.1 需求分析](#31-需求分析)
+ - [3.2 可行性分析](#32-可行性分析)
+ - [3.3 用例图](#33-用例图)
+ - [3.4 用例描述](#34-用例描述)
+ - [3.5 系统性能分析](#35-系统性能分析)
+- [第4章 爱维宠物医院管理系统设计](#第4章-爱维宠物医院管理系统设计)
+ - [4.1 系统功能设计](#41-系统功能设计)
+ - [4.2 类图设计](#42-类图设计)
+ - [4.3 序列图设计](#43-序列图设计)
+ - [4.4 活动图设计](#44-活动图设计)
+ - [4.5 数据库设计](#45-数据库设计)
+ - [4.6 图形界面设计](#46-图形界面设计)
+- [第5章 爱维宠物医院管理系统实现](#第5章-爱维宠物医院管理系统实现)
+ - [5.1 用户功能模块实现](#51-用户功能模块实现)
+ - [5.2 医生功能模块实现](#52-医生功能模块实现)
+ - [5.3 管理员功能模块实现](#53-管理员功能模块实现)
+- [第6章 爱维宠物医院管理系统测试](#第6章-爱维宠物医院管理系统测试)
+ - [6.1 系统测试概述](#61-系统测试概述)
+ - [6.2 系统测试用例设计](#62-系统测试用例设计)
+ - [6.3 测试结果分析](#63-测试结果分析)
+- [第7章 结论](#第7章-结论)
+- [参考文献](#参考文献)
+- [致谢](#致谢)
+
+## 第1章 绪论
+
+### 1.1 课题来源及意义
+
+近年来，宠物在人们家庭生活中的角色由“附属饲养对象”逐步演变为“长期陪伴成员”，宠物健康服务需求随之快速增长。与市场规模扩张相比，部分宠物医院的信息化建设相对滞后，仍以人工登记、线下排队与分散记录为主，导致运营效率与服务体验难以同步提升。
+
+本课题来源于宠物医院真实业务痛点，旨在构建一套覆盖“预约-接诊-病历-处方-库存-结算-统计”链路的管理平台。课题意义主要体现在三个方面：
+
+1. 业务规范化：通过流程化系统替代低效人工操作，降低关键环节差错率；
+2. 数据可追溯：建立统一数据模型，保证诊疗、用药、库存与订单之间的关联关系；
+3. 服务可持续：为后续功能扩展（如在线支付、提醒通知、数据分析）提供可演进架构。
+
+### 1.2 课题研究现状
+
+国外宠物医疗信息化实践起步较早，常见系统已支持线上预约、电子病历、处方流转与经营分析，并在智能化方向探索远程服务和决策支持。国内相关系统近年来发展迅速，更多集中于基础业务数字化建设，包括用户管理、预约管理、病历与处方管理、药品库存管理等。
+
+总体来看，当前国内同类系统在“业务闭环完整性”和“系统集成深度”方面仍有提升空间，尤其体现在支付闭环、提醒机制、跨角色协同与深度统计分析等方面。因此，结合本地场景构建可落地、可迭代的宠物医院管理系统具有现实价值。
+
+### 1.3 当前存在的问题
+
+经需求调研与项目分析，宠物医院管理现状主要存在以下问题：
+
+1. 预约环节缺乏统一调度，容易出现时间冲突或人工确认延迟；
+2. 病历与处方数据分散，历史信息检索与复用效率较低；
+3. 药品出入库记录与诊疗流程联动不足，库存预警能力有限；
+4. 顾客端在线服务入口不足，查询、跟踪、反馈体验不连续；
+5. 经营统计维度有限，难以支撑精细化运营决策。
+
+### 1.4 课题研究目标
+
+本课题目标是在现有业务流程基础上实现一套可运行、可管理、可扩展的宠物医院管理系统，具体目标如下：
+
+1. 建立面向管理员、医生、顾客三类角色的统一业务平台；
+2. 打通预约、接诊、病历、处方、订单、库存的核心业务链路；
+3. 提供基础权限控制、数据校验与接口规范，提升系统可靠性；
+4. 形成可用于毕业设计论文的完整系统分析、设计、实现与测试材料。
+
+### 1.5 研究内容与论文结构安排
+
+围绕课题目标，本文从“问题定义、技术路径、系统落地、效果验证”四个层面展开。第一步，通过业务调研明确宠物医院在预约、接诊、病历、处方、库存和运营统计中的关键痛点；第二步，基于前后端分离思想确定技术选型与系统边界，构建可扩展的模块化架构；第三步，结合角色职责进行功能设计与实现，确保顾客、医生、管理员三端能力协同；第四步，采用功能测试与流程测试相结合的方法验证系统可用性，归纳不足并提出后续优化路线。
+
+从论文组织上看，第1章给出研究背景和目标；第2章阐述技术基础与开发模式；第3章完成需求、可行性与用例分析；第4章进行架构、数据库与界面设计；第5章描述系统实现结果；第6章给出测试方案与结果分析；第7章总结研究成果并提出展望。该结构遵循“先分析、后设计、再实现、终测试”的工程论文写作逻辑，能够保证论证链条完整、内容前后呼应。
+
+## 第2章 主要技术和框架
+
+### 2.1 主要技术
+
+#### 2.1.1 后端技术
+
+- Spring Boot：用于构建后端服务，简化项目配置并提升开发效率；
+- Spring Security：负责身份认证与访问控制；
+- MyBatis-Plus：简化数据库 CRUD 与分页查询实现；
+- MySQL：承担核心业务数据持久化存储；
+- JWT：实现无状态登录认证与角色信息传递。
+
+#### 2.1.2 前端技术
+
+- Vue3：用于构建组件化前端应用；
+- Vue Router：实现多角色页面路由与导航守卫；
+- Pinia：负责用户认证状态与全局状态管理；
+- Axios：用于封装接口请求；
+- TDesign Vue Next：提供基础 UI 组件与交互能力；
+- Vite：作为前端构建与开发工具。
+
+### 2.2 框架和开发模式
+
+#### 2.2.1 前后端分离开发模式
+
+系统采用前后端分离模式。后端提供 REST 风格接口，前端通过 HTTP 请求调用业务能力。这种模式有利于角色页面独立演进、接口复用与后期多端扩展。
+
+#### 2.2.2 RBAC 权限模型
+
+系统围绕角色进行权限约束，核心角色包括：
+
+- `ADMIN`：系统级管理权限，负责用户、药品、统计与全局数据管理；
+- `DOCTOR`：诊疗业务权限，负责接诊、病历、处方等专业操作；
+- `CUSTOMER`：顾客自助权限，负责预约、宠物档案与个人查询服务。
+
+#### 2.2.3 统一接口与数据规范
+
+系统在接口层使用统一响应结构，并在数据层采用逻辑删除与统一时间戳字段（创建/更新时间），保障数据生命周期管理与后续审计扩展能力。
+
+### 2.3 技术选型对比与决策依据
+
+在技术选型过程中，项目遵循“满足业务需求优先、学习与维护成本可控、后续扩展路径清晰”的原则。后端框架方面，最终选择 Spring Boot 作为主框架，主要考虑其在企业级开发中的成熟度高、生态完整、与安全和数据访问组件集成成本低。与传统手工整合方案相比，Spring Boot 在工程初始化、依赖管理、运行维护和配置管理方面具有明显优势，能够缩短开发周期并降低环境差异带来的风险。
+
+在数据访问层，项目选择 MyBatis-Plus 而非仅使用原生 MyBatis，核心原因是其在保留灵活 SQL 能力的同时提供了高频 CRUD 能力、分页支持与统一条件构造方式，适合毕业设计阶段多实体并行开发场景。数据库方面采用 MySQL，主要考虑其在事务一致性、索引优化和部署便利性上的综合平衡，能够满足中小规模业务系统的数据存储需求。
+
+前端技术方面，选择 Vue3 + Vite 的组合，以获得更好的开发体验与构建效率。Vue3 的组合式 API 适合中型系统按业务模块拆分组件，便于后续维护；Vite 在本地开发热更新和生产构建方面效率较高。状态管理采用 Pinia，路由管理采用 Vue Router，二者与 Vue3 官方生态契合度高，有利于实现角色隔离与导航守卫。UI 组件库选择 TDesign，能够较快完成后台型界面的统一风格建设，减少重复样式开发工作。
+
+安全机制方面，系统采用 Spring Security + JWT 的组合。相较于传统会话机制，JWT 在前后端分离场景下更便于跨服务身份携带与无状态认证，同时降低服务端会话存储负担。考虑到毕业设计系统规模与部署方式，该方案在复杂度与可用性之间实现了较好平衡。
+
+### 2.4 本章小结
+
+本章围绕系统实现所需的技术基础进行了梳理，并给出了关键技术选型的决策理由。通过对后端框架、前端框架、数据访问方案、鉴权模式和工程化工具的综合比较，确定了本项目的技术路线。该路线不仅能够支撑当前业务需求实现，也为后续功能扩展与系统优化提供了稳定基础。
+
+## 第3章 爱维宠物医院管理系统分析
+
+### 3.1 需求分析
+
+#### 3.1.1 功能需求分析
+
+1. 顾客侧：注册登录、宠物档案维护、门诊预约、订单查询、报告查询；
+2. 医生侧：预约接诊、就诊记录、病历维护、处方开具与查看；
+3. 管理侧：账户管理、公告管理、药品与库存管理、统计分析。
+
+#### 3.1.2 性能需求分析
+
+1. 响应性：常规查询与列表展示应保持较快响应，避免长时间等待；
+2. 并发性：满足中小型机构多岗位并行操作的基础并发访问需求；
+3. 可用性：关键业务模块应具备稳定运行能力，避免核心流程中断；
+4. 可维护性：模块边界清晰，便于后续扩展与缺陷修复。
+
+#### 3.1.3 详细业务需求分解
+
+为保证需求可执行、可测试，本系统进一步将核心需求拆分为角色维度和流程维度两类。
+
+（1）顾客角色需求分解：
+
+1. 账户能力：支持注册、登录、身份保持、个人资料维护；
+2. 宠物能力：支持宠物档案新增、编辑、删除和按主人维度查询；
+3. 预约能力：支持选择日期时段提交预约、查询预约记录、查看预约状态；
+4. 查询能力：支持订单信息查询、报告信息查询和历史数据浏览；
+5. 交互能力：支持通过公告或留言渠道获取医院通知与反馈入口。
+
+（2）医生角色需求分解：
+
+1. 接诊能力：支持按预约或就诊对象进入接诊流程；
+2. 病历能力：支持主诉、检查结果、诊断结论和处理建议的结构化录入；
+3. 处方能力：支持处方创建、处方项维护、处方状态流转；
+4. 检索能力：支持按宠物、顾客和时间维度查询历史记录。
+
+（3）管理员角色需求分解：
+
+1. 用户能力：支持用户列表管理、状态管理和角色可见范围控制；
+2. 公告能力：支持公告发布、更新和状态管理；
+3. 药品能力：支持药品信息维护、入库出库记录管理；
+4. 统计能力：支持基础经营数据展示，辅助运营判断。
+
+（4）流程协同需求分解：
+
+1. 预约到接诊：顾客预约信息应可被医生侧检索并用于创建就诊记录；
+2. 接诊到病历：就诊记录应可关联病历，形成连续诊疗轨迹；
+3. 病历到处方：病历结论应支持医生创建处方并维护处方明细；
+4. 处方到库存：处方用药应能够支撑库存管理场景的数据联动（当前实现基础联动）；
+5. 全链路可追溯：关键业务对象均需记录创建时间、更新时间和状态字段。
+
+#### 3.1.4 非功能需求细化
+
+（1）性能需求：
+
+系统在常见操作场景下需保持流畅交互体验，分页查询、筛选查询与表单提交应在可接受时延范围内完成。对于批量数据展示场景，优先采用分页和条件查询策略，避免一次性加载过多数据导致前后端压力集中。
+
+（2）安全需求：
+
+系统需保证认证有效性与权限边界清晰性。未认证请求不得访问受限资源；不同角色之间应按职责隔离页面与接口可见范围；关键表单数据应进行参数合法性约束，避免无效或异常输入直接进入业务流程。
+
+（3）可用性需求：
+
+系统应具备清晰的操作反馈机制，包括成功提示、失败提示和状态展示，减少用户因信息不透明导致的误操作。对常见业务页面采用统一布局与交互习惯，降低学习成本。
+
+（4）可维护性需求：
+
+系统模块应按职责划分，便于后续局部迭代。接口命名、状态字段、时间字段和删除策略应统一，以减少维护过程中的理解偏差。文档与图表需与系统版本同步更新，确保“文档可追踪、实现可验证”。
+
+（5）可扩展性需求：
+
+在不大幅重构现有架构的前提下，系统应具备接入支付能力、提醒能力、报表导出能力和更多统计维度的空间。新增业务应尽量在现有数据模型基础上做增量扩展，而非破坏既有核心表结构。
+
+### 3.2 可行性分析
+
+#### 3.2.1 技术可行性
+
+本系统所采用技术栈成熟、社区生态完善，能够支持角色权限、业务流程编排、数据持久化与前端交互等核心需求。前后端分离模式对团队协作和功能增量开发友好，技术风险可控。
+
+#### 3.2.2 经济可行性
+
+系统主要采用开源技术框架，部署成本与维护成本较低，适合中小型宠物医院信息化建设预算。系统上线后可减少重复劳动，降低人工运营成本，具备投入产出合理性。
+
+#### 3.2.3 社会可行性
+
+宠物医疗数字化符合行业发展趋势。系统建设有助于提升诊疗流程透明度和服务可达性，增强用户信任，对提升宠物医疗服务质量具有积极意义。
+
+### 3.3 用例图
+
+#### 3.3.1 顾客用例图
+
+顾客角色的核心用例包括：注册登录、维护宠物档案、提交预约、查看订单、查询报告。
+
+（图3.1 顾客用例图）
+
+#### 3.3.2 医生用例图
+
+医生角色的核心用例包括：查看预约、创建就诊记录、编辑病历、开具处方、查询历史记录。
+
+（图3.2 医生用例图）
+
+#### 3.3.3 管理员用例图
+
+管理员角色的核心用例包括：用户管理、公告管理、药品库存管理、统计报表查看。
+
+（图3.3 管理员用例图）
+
+### 3.4 用例描述
+
+#### 3.4.1 顾客预约门诊用例描述
+
+| 项目 | 描述 |
+|---|---|
+| 用例名称 | 顾客预约门诊 |
+| 执行者 | 顾客 |
+| 前置条件 | 顾客已登录且已绑定至少一只宠物 |
+| 后置条件 | 生成预约记录，状态为待处理或已确认 |
+| 基本事件流 | 进入预约页面 → 选择宠物、日期、时段及医生（可选）→ 提交预约 → 系统保存记录并返回结果 |
+| 异常事件流 | 必填信息缺失或时段不可用时，系统提示重新选择 |
+
+#### 3.4.2 医生开具处方用例描述
+
+| 项目 | 描述 |
+|---|---|
+| 用例名称 | 医生开具处方 |
+| 执行者 | 医生 |
+| 前置条件 | 已存在有效就诊记录 |
+| 后置条件 | 生成处方主记录与处方明细记录 |
+| 基本事件流 | 进入处方模块 → 选择就诊对象 → 录入药品与用法用量 → 提交处方 |
+| 异常事件流 | 药品信息不完整或状态不允许提交时，系统阻止提交并提示 |
+
+#### 3.4.3 管理员药品入库用例描述
+
+| 项目 | 描述 |
+|---|---|
+| 用例名称 | 管理员药品入库 |
+| 执行者 | 管理员 |
+| 前置条件 | 管理员已登录且拥有库存管理权限 |
+| 后置条件 | 入库记录写入并更新药品库存 |
+| 基本事件流 | 进入入库管理 → 选择药品并填写数量、单价、供应信息 → 提交入库 |
+| 异常事件流 | 输入数据非法时，系统提示修正后再提交 |
+
+### 3.5 系统性能分析
+
+1. 交互性能：前端分页查询与后端分页接口配合，降低一次性数据加载压力；
+2. 数据性能：通过明确实体关系、主外键关联与状态字段管理，保障常用查询稳定性；
+3. 安全性能：基于 JWT 与角色权限约束降低越权访问风险；
+4. 运行稳定性：关键模块采用统一接口与异常处理思路，降低业务中断概率。
+
+### 3.6 业务风险与约束分析
+
+为提升系统实施质量，需在分析阶段明确项目风险与边界约束。
+
+（1）业务风险：
+
+1. 预约高峰时段可能出现集中提交，若缺少冲突检测会降低预约可靠性；
+2. 病历与处方属于高敏感业务数据，若权限边界设置不清晰将带来数据泄露风险；
+3. 库存数据与实际消耗存在时间差时，可能引发“账实不一致”问题；
+4. 支付闭环未完整接入前，订单状态与真实支付状态可能存在管理间隙。
+
+（2）技术风险：
+
+1. 前后端字段定义不一致将导致接口联调失败；
+2. 状态字段语义不统一会增加流程判断复杂度；
+3. 历史数据持续增长后，分页和筛选查询需要进一步优化索引策略。
+
+（3）管理约束：
+
+1. 毕业设计周期有限，需要优先保证核心主链路闭环；
+2. 测试资源有限，应优先覆盖高风险模块与高频场景；
+3. 论文写作需与系统版本保持一致，避免“实现与描述脱节”。
+
+### 3.7 本章小结
+
+本章完成了系统需求、可行性、用例与性能分析，并从业务和技术两个维度识别了主要风险点。通过将需求从“功能清单”细化为“可执行约束”，为后续系统设计与实现提供了清晰输入，确保第4章设计内容能够直接映射到第5章实现与第6章测试。
+
+## 第4章 爱维宠物医院管理系统设计
+
+### 4.1 系统功能设计
+
+系统总体由三类角色构成：顾客、医生、管理员。功能结构围绕“业务执行端（顾客、医生）+运营管理端（管理员）”组织。
+
+#### 4.1.1 顾客功能结构
+
+顾客端主要包括：首页与公告浏览、宠物档案管理、预约管理、订单与报告查询等功能。
+
+（图4.1 顾客功能结构图）
+
+#### 4.1.2 医生功能结构
+
+医生端主要包括：预约接诊、就诊记录、病历维护、处方管理等功能。
+
+（图4.2 医生功能结构图）
+
+#### 4.1.3 管理员功能结构
+
+管理员端主要包括：用户管理、公告管理、药品管理、库存流水管理、统计分析等功能。
+
+（图4.3 管理员功能结构图）
+
+### 4.2 类图设计
+
+系统核心实体包含 `User`、`Doctor`、`Pet`、`Appointment`、`Visit`、`MedicalRecord`、`Prescription`、`PrescriptionItem`、`Drug`、`OrderInfo`、`StockIn`、`StockOut`、`Notice`、`Report` 等。
+
+主要关系如下：
+
+1. 用户与宠物为一对多关系；
+2. 顾客与预约为一对多关系；
+3. 预约与就诊记录存在关联关系；
+4. 就诊与病历、处方均存在业务关联；
+5. 处方与处方明细为一对多关系；
+6. 药品与出入库记录为一对多关系。
+
+（图4.4 系统类图）
+
+### 4.3 序列图设计
+
+#### 4.3.1 顾客预约门诊序列图
+
+顾客发起预约请求后，系统完成参数校验、业务检查与记录保存，再将结果返回前端展示。
+
+（图4.5 顾客预约序列图）
+
+#### 4.3.2 管理员账号管理序列图
+
+管理员在用户管理模块发起新增/更新/禁用操作，系统校验权限并更新目标用户状态。
+
+（图4.6 管理员账号管理序列图）
+
+### 4.4 活动图设计
+
+#### 4.4.1 医生接诊活动图
+
+流程为：登录系统 → 查看预约 → 确认到诊 → 创建就诊记录 → 完成病历录入 → 处方处理 → 结束接诊。
+
+（图4.7 医生就诊活动图）
+
+#### 4.4.2 顾客预约活动图
+
+流程为：登录系统 → 选择宠物与时段 → 提交预约信息 → 系统校验并保存 → 返回预约结果。
+
+（图4.8 顾客预约活动图）
+
+### 4.5 数据库设计
+
+#### 4.5.1 概念设计
+
+根据业务分析，系统包含用户、医生、宠物、预约、就诊、病历、处方、药品、订单、公告、库存流水、报告等核心实体，覆盖诊疗与运营管理全链路。
+
+（图4.9 实体属性图）
+
+（图4.10 系统 E-R 图）
+
+#### 4.5.2 逻辑设计
+
+关系模式示例如下（主键以 PK 标识，外键以 FK 标识）：
+
+1. 用户表：`user`(id PK, username, phone, email, password, role, status, avatar, create_time, update_time, deleted)
+2. 医生表：`doctor`(id PK, name, department, title, phone, email, status, create_time, update_time, deleted)
+3. 宠物表：`pet`(id PK, owner_id FK, name, species, breed, gender, birthday, weight, remark, create_time, update_time, deleted)
+4. 预约表：`appointment`(id PK, customer_id FK, pet_id FK, doctor_id FK, department, appointment_date, time_slot, status, remark, create_time, update_time, deleted)
+5. 就诊表：`visit`(id PK, appointment_id FK, customer_id FK, pet_id FK, doctor_id FK, symptoms, diagnosis, treatment_plan, status, payment_status, create_time, update_time, deleted)
+6. 病历表：`medical_record`(id PK, visit_id FK, doctor_id FK, content, record_type, create_time, update_time, deleted)
+7. 处方表：`prescription`(id PK, visit_id FK, doctor_id FK, customer_id FK, total_amount, status, create_time, update_time, deleted)
+8. 处方明细表：`prescription_item`(id PK, prescription_id FK, drug_id FK, quantity, dosage, frequency, duration, create_time, update_time, deleted)
+9. 药品表：`drug`(id PK, name, category, specification, unit_price, stock_quantity, alert_threshold, status, create_time, update_time, deleted)
+10. 订单表：`order_info`(id PK, visit_id FK, customer_id FK, amount, status, payment_method, payment_time, create_time, update_time, deleted)
+11. 入库表：`stock_in`(id PK, drug_id FK, quantity, unit_price, supplier, operator_id FK, create_time, update_time, deleted)
+12. 出库表：`stock_out`(id PK, drug_id FK, quantity, purpose, operator_id FK, create_time, update_time, deleted)
+
+#### 4.5.3 物理设计
+
+以下选取部分核心物理表结构说明：
+
+**表4.1 用户表（user）**
+
+| 字段名称 | 字段含义 | 类型 | 约束 |
+|---|---|---|---|
+| id | 用户主键 | BIGINT | PK, 自增 |
+| username | 用户名 | VARCHAR(50) | 唯一、非空 |
+| password | 密码密文 | VARCHAR(255) | 非空 |
+| role | 角色 | VARCHAR(20) | 非空 |
+| status | 状态 | INT | 默认有效 |
+
+**表4.2 宠物表（pet）**
+
+| 字段名称 | 字段含义 | 类型 | 约束 |
+|---|---|---|---|
+| id | 宠物主键 | BIGINT | PK, 自增 |
+| owner_id | 主人用户ID | BIGINT | FK, 非空 |
+| name | 宠物名称 | VARCHAR(50) | 非空 |
+| species | 物种 | VARCHAR(50) | |
+| birthday | 出生日期 | DATE | |
+
+**表4.3 预约表（appointment）**
+
+| 字段名称 | 字段含义 | 类型 | 约束 |
+|---|---|---|---|
+| id | 预约主键 | BIGINT | PK, 自增 |
+| customer_id | 顾客ID | BIGINT | FK, 非空 |
+| pet_id | 宠物ID | BIGINT | FK, 非空 |
+| appointment_date | 预约日期 | DATE | 非空 |
+| time_slot | 时段 | VARCHAR(20) | 非空 |
+
+**表4.4 就诊表（visit）**
+
+| 字段名称 | 字段含义 | 类型 | 约束 |
+|---|---|---|---|
+| id | 就诊主键 | BIGINT | PK, 自增 |
+| appointment_id | 预约ID | BIGINT | FK |
+| doctor_id | 医生ID | BIGINT | FK, 非空 |
+| diagnosis | 诊断结果 | TEXT | |
+| status | 就诊状态 | VARCHAR(20) | 业务状态 |
+
+**表4.5 处方表（prescription）**
+
+| 字段名称 | 字段含义 | 类型 | 约束 |
+|---|---|---|---|
+| id | 处方主键 | BIGINT | PK, 自增 |
+| visit_id | 就诊ID | BIGINT | FK |
+| doctor_id | 医生ID | BIGINT | FK |
+| total_amount | 处方金额 | DECIMAL(10,2) | |
+| status | 处方状态 | VARCHAR(20) | |
+
+**表4.6 药品表（drug）**
+
+| 字段名称 | 字段含义 | 类型 | 约束 |
+|---|---|---|---|
+| id | 药品主键 | BIGINT | PK, 自增 |
+| name | 药品名称 | VARCHAR(100) | 非空 |
+| category | 药品分类 | VARCHAR(50) | |
+| stock_quantity | 当前库存 | INT | 默认0 |
+| alert_threshold | 预警阈值 | INT | |
+
+**表4.7 订单表（order_info）**
+
+| 字段名称 | 字段含义 | 类型 | 约束 |
+|---|---|---|---|
+| id | 订单主键 | BIGINT | PK, 自增 |
+| customer_id | 顾客ID | BIGINT | FK, 非空 |
+| amount | 金额 | DECIMAL(10,2) | |
+| status | 订单状态 | VARCHAR(20) | 非空 |
+| payment_method | 支付方式 | VARCHAR(20) | |
+
+**表4.8 库存入库表（stock_in）**
+
+| 字段名称 | 字段含义 | 类型 | 约束 |
+|---|---|---|---|
+| id | 入库主键 | BIGINT | PK, 自增 |
+| drug_id | 药品ID | BIGINT | FK, 非空 |
+| quantity | 入库数量 | INT | 非空 |
+| unit_price | 入库单价 | DECIMAL(10,2) | |
+| operator_id | 操作人ID | BIGINT | FK |
+
+### 4.6 图形界面设计
+
+系统界面按角色分层设计：
+
+1. 顾客端采用简化入口，突出预约、宠物、订单、报告等高频功能；
+2. 医生端强调业务连续性，突出接诊、病历与处方操作路径；
+3. 管理端突出数据与配置能力，侧重用户、库存与统计管理。
+
+示例界面包括预约挂号、病历录入、药品库存管理等场景。
+
+（图4.11 预约挂号界面设计图）
+
+（图4.12 药品库存管理界面设计图）
+
+（图4.13 病历书写界面设计图）
+
+### 4.7 系统部署与运行设计
+
+系统部署采用“前后端分离 + 统一数据库”的基础形态。后端服务作为 API 提供方，前端通过浏览器访问并调用接口，数据库负责统一存储业务数据。部署过程重点关注以下内容：
+
+1. 环境一致性：开发、测试与演示环境应尽量保持配置一致，减少“本地可用、部署异常”问题；
+2. 配置隔离：数据库连接、鉴权密钥、文件路径等配置项应按环境分离，避免硬编码带来的维护风险；
+3. 日志可追踪：关键业务操作与异常信息需可检索，便于问题定位与回归分析；
+4. 启停可控：系统启动顺序遵循“数据库优先、后端次之、前端最后”，保证联调过程稳定。
+
+此外，考虑到毕业设计场景通常以演示环境为主，系统优先保障“核心流程稳定可复现”，即顾客预约、医生接诊、管理员库存管理三条主流程在标准演示数据下可连续运行。
+
+### 4.8 安全与数据一致性设计
+
+系统在设计阶段引入“认证、授权、校验、追踪”四层控制思想：
+
+1. 认证层：通过令牌机制识别请求身份，防止匿名访问受限资源；
+2. 授权层：依据角色限制页面与接口访问边界，避免越权操作；
+3. 校验层：对关键输入进行合法性检查，减少异常数据进入业务流程；
+4. 追踪层：通过时间字段、状态字段和逻辑删除策略保留数据演化轨迹。
+
+在数据一致性方面，系统通过实体关联关系约束业务对象之间的上下文，尽量避免孤立记录。例如预约、就诊、病历、处方在语义上形成有序链路，能够支持后续追踪与统计。对于库存数据，系统采用“主数据 + 流水记录”方式保留变更依据，便于后续核对与审计。
+
+### 4.9 本章小结
+
+本章从功能结构、对象关系、交互流程、数据库结构、界面设计、部署方案及安全一致性策略等方面完成了系统设计。设计结果强调“结构清晰、流程可追溯、实现可落地”，为第5章功能实现提供了明确蓝图。
+
+## 第5章 爱维宠物医院管理系统实现
+
+本章仅描述主要功能实现结果，不展示开发代码。
+
+### 5.1 用户功能模块实现
+
+#### 5.1.1 顾客首页与个人中心
+
+顾客进入系统后可在首页查看公告与功能入口，并在个人中心维护基础资料。该模块用于统一承载顾客端高频操作入口，提升功能可达性与使用连续性。
+
+#### 5.1.2 宠物档案管理
+
+顾客可新增、查看、编辑和删除宠物档案，支持维护宠物基本信息及历史关联信息。该模块为预约与就诊流程提供基础数据支撑。
+
+#### 5.1.3 门诊预约与订单查询
+
+顾客可提交预约请求并查看历史预约记录，同时可查询订单状态与报告信息，实现从预约到结果查询的基础闭环。
+
+### 5.2 医生功能模块实现
+
+#### 5.2.1 门诊接诊与就诊记录
+
+医生可查看预约数据并完成接诊处理，创建就诊记录以承载后续病历和处方业务。
+
+#### 5.2.2 病历管理
+
+医生可对就诊对象进行病历录入与维护，支持按就诊维度归档管理，提高历史复诊信息可追溯性。
+
+#### 5.2.3 处方管理
+
+医生可创建处方并维护处方明细，实现用药信息结构化管理，为订单与库存联动奠定基础。
+
+### 5.3 管理员功能模块实现
+
+#### 5.3.1 账户与公告管理
+
+管理员可对用户进行统一管理，并通过公告模块发布运营通知与服务信息。
+
+#### 5.3.2 药品与库存管理
+
+管理员可维护药品档案，并通过入库、出库模块记录库存变更，实现基础库存可视化管理。
+
+#### 5.3.3 统计分析
+
+系统提供基础统计页面，用于展示关键经营数据，为管理决策提供直观参考。
+
+### 5.4 关键业务流程实现结果
+
+#### 5.4.1 预约到接诊流程实现结果
+
+系统已实现顾客提交预约、医生查看预约并处理接诊的基础流程。顾客端可完成预约信息录入和历史查询，医生端可在工作页面查看待处理信息并进入接诊环节。该流程实现的价值在于将原先分散的人工登记环节转化为可检索、可跟踪、可回溯的数据流程，减少信息遗漏。
+
+#### 5.4.2 接诊到病历处方流程实现结果
+
+在医生侧，系统支持围绕就诊对象建立病历记录并创建处方信息，病历和处方形成结构化关联。相较于纸质记录方式，电子化记录在检索效率、信息完整性与复诊复用方面具有明显优势。通过角色页面分层，医生可聚焦诊疗核心操作，降低非必要管理项干扰。
+
+#### 5.4.3 库存管理流程实现结果
+
+管理员侧已实现药品基础信息维护与出入库记录管理。系统可记录库存变更来源，支撑基础库存可视化。该流程在日常管理中的意义体现在：一是降低“库存不明”导致的业务中断概率，二是为后续构建库存预警、采购建议和用药统计提供数据基础。
+
+#### 5.4.4 信息发布与运营支撑实现结果
+
+系统支持公告发布与基础统计展示。公告能力提升了医院与顾客之间的信息触达效率，统计能力为管理者提供了运营观察窗口。虽然当前统计维度仍以基础指标为主，但已具备继续扩展到多维分析的结构条件。
+
+### 5.5 模块实现成效评估
+
+从系统落地效果看，核心模块实现具备以下特点：
+
+1. 业务主链路可运行：预约、接诊、病历、处方、库存、统计等核心模块已打通；
+2. 角色边界较清晰：顾客、医生、管理员各自聚焦对应职责范围；
+3. 数据组织较规范：关键对象具备状态与时间维度，便于追踪；
+4. 扩展方向明确：在线支付、提醒通知、导出能力等可在现有架构上增量演进。
+
+### 5.6 本章小结
+
+本章围绕系统实现结果进行了模块化说明，重点强调“做成了什么、支撑了什么业务、还差什么能力”。在不展示开发代码的前提下，论文仍能清晰体现系统功能落地情况与工程价值，为测试章节提供可验证对象。
+
+## 第6章 爱维宠物医院管理系统测试
+
+### 6.1 系统测试概述
+
+#### 6.1.1 测试背景
+
+系统完成主要功能开发后，需要通过测试验证业务流程完整性、角色权限有效性与核心模块稳定性。
+
+#### 6.1.2 测试意义
+
+测试可以及时发现流程断点、权限漏洞和交互异常，确保系统在真实业务场景中可用。
+
+#### 6.1.3 测试环境
+
+测试环境由后端服务、前端页面与 MySQL 数据库组成，采用角色账户分别进行业务验证。
+
+### 6.2 系统测试用例设计
+
+#### 6.2.1 用户认证功能测试
+
+| 测试项 | 输入 | 预期结果 |
+|---|---|---|
+| 正常登录 | 正确账号与密码 | 登录成功并进入角色首页 |
+| 错误密码 | 正确账号+错误密码 | 登录失败并提示错误信息 |
+| 未授权访问 | 未登录访问受限页面 | 跳转至登录页 |
+
+#### 6.2.2 预约功能测试
+
+| 测试项 | 操作 | 预期结果 |
+|---|---|---|
+| 新增预约 | 顾客提交合法预约信息 | 预约记录创建成功 |
+| 预约列表查询 | 顾客查看个人预约列表 | 返回该顾客关联记录 |
+| 状态更新 | 医生/管理员更新预约状态 | 状态变更成功 |
+
+#### 6.2.3 病历与处方功能测试
+
+| 测试项 | 操作 | 预期结果 |
+|---|---|---|
+| 创建病历 | 医生提交病历信息 | 病历记录创建成功 |
+| 创建处方 | 医生提交处方与明细 | 处方与明细均成功保存 |
+| 历史查询 | 按条件查询病历/处方 | 可返回匹配记录 |
+
+#### 6.2.4 安全性测试
+
+1. 角色权限测试：验证顾客、医生、管理员访问边界；
+2. 认证有效性测试：验证无令牌、过期令牌访问控制效果；
+3. 参数合法性测试：验证关键输入项的约束与错误提示。
+
+#### 6.2.5 兼容性测试
+
+系统在主流桌面浏览器下进行页面访问与核心功能操作验证，确保常见使用环境下的可用性。
+
+### 6.3 测试结果分析
+
+经测试，系统核心模块可稳定运行，认证与权限控制整体有效，顾客预约、医生接诊、病历处方、管理员库存管理等主路径可完成。当前系统在以下方面仍有提升空间：
+
+1. 在线支付能力尚未形成完整闭环；
+2. 预约提醒、库存主动预警等自动化能力仍需增强；
+3. 个别扩展模块的前端覆盖仍有完善空间。
+
+### 6.4 缺陷跟踪与回归测试
+
+为保证测试结论可靠，系统在功能测试后进行了缺陷分类与回归验证。缺陷主要分为三类：
+
+1. 交互提示类：如状态提示文案不明确、失败反馈不够具体；
+2. 流程一致性类：如部分状态流转条件不够严格导致边界场景处理不统一；
+3. 权限边界类：如个别页面在前端路由层和后端接口层的限制策略需进一步对齐。
+
+回归测试以“高频场景优先、关键流程优先”为原则，重点覆盖登录鉴权、预约提交、病历录入、处方创建、库存操作等模块。经过回归后，核心流程可保持稳定运行，未出现阻断级问题。
+
+### 6.5 测试数据与结果汇总说明
+
+从测试覆盖角度看，系统已覆盖认证、预约、病历、处方、库存、权限和兼容性等核心方向，能够满足毕业设计验收阶段的基本要求。测试结果表明：
+
+1. 功能完整性方面：核心业务功能可用，主路径闭环可执行；
+2. 稳定性方面：常见操作下系统运行稳定，未出现持续性错误；
+3. 安全性方面：角色访问边界总体有效，认证策略可生效；
+4. 可用性方面：页面交互路径清晰，具备基础业务操作友好性。
+
+需要进一步强化的方面包括支付闭环、消息提醒和高级统计报表能力。上述问题不影响系统主体功能验收，但会影响长期运营深度，建议作为后续迭代重点。
+
+### 6.6 本章小结
+
+本章通过测试环境说明、用例设计、结果分析、缺陷回归与汇总结论，验证了系统“可运行、可使用、可改进”的总体状态。测试结论与第5章实现结果一致，能够支撑论文结论部分的客观论证。
+
+## 第7章 结论
+
+本文围绕宠物医院信息化管理需求，完成了爱维宠物医院管理系统的分析、设计、实现与测试工作。系统在多角色协同、核心业务流程打通、基础安全控制和数据结构化管理方面达到了预期目标，能够支撑中小型宠物医院的日常运营。
+
+同时，本文也明确了系统后续优化方向：完善支付与提醒闭环、增强运营分析深度、进一步提升业务自动化程度。未来可在既有架构基础上逐步引入智能排班、风险预警与数据驱动决策能力，持续提升系统业务价值与行业适配能力。
+
+### 7.1 主要研究成果
+
+本文在毕业设计周期内完成了从需求分析到系统测试的完整工程闭环，主要成果可概括为：
+
+1. 构建了面向三角色的宠物医院管理系统原型，形成较完整的业务能力框架；
+2. 打通了预约、接诊、病历、处方、库存与统计等核心流程，具备实际演示与应用价值；
+3. 建立了较规范的数据模型与接口约束机制，为后续扩展奠定基础；
+4. 形成了可复用的分析、设计、实现和测试文档体系，为同类项目提供参考。
+
+### 7.2 不足与改进空间
+
+尽管系统已实现核心目标，但仍存在若干不足：
+
+1. 支付能力仍以基础状态管理为主，尚未形成完整第三方支付闭环；
+2. 预约提醒、库存预警等主动通知机制仍需增强；
+3. 统计分析维度偏基础，尚未形成更精细化的运营洞察；
+4. 部分扩展功能的页面覆盖与交互细节仍有优化空间。
+
+上述不足主要受毕业设计周期、测试资源和外部接口条件限制。后续可按“先闭环、后智能、再优化体验”的路线逐步推进。
+
+### 7.3 后续工作展望
+
+面向实际应用场景，后续工作可从以下方向深化：
+
+1. 支付闭环建设：对接主流支付渠道，完善订单状态回调与异常处理；
+2. 提醒系统建设：引入预约提醒、复诊提醒、库存阈值提醒，提高运营主动性；
+3. 统计分析升级：补充多维报表、趋势分析和可视化导出能力；
+4. 智能化拓展：探索基于历史数据的排班优化、用药趋势分析与风险预警；
+5. 工程化升级：完善自动化测试与持续集成流程，提高版本交付稳定性。
+
+综上，爱维宠物医院管理系统已具备从“可用”走向“好用、易扩展”的基础条件。随着后续迭代推进，系统有望在中小型宠物医疗机构的信息化建设中发挥更大价值。
+
+## 参考文献
+
+[1] 王慧. 一个宠物医院管理系统的设计与实现[J]. 电脑知识与技术, 2023(10):67-70.
+[2] 田斌. 基于SSM框架的宠物医院系统设计[J]. 无线互联科技, 2023(14):69-71.
+[3] K. Nandhini. Veterinary Hospital Management System Using AI Integrated Advisory[J]. International Journal of Science, Engineering and Technology, 2025, 13(2).
+[4] 颜惠. 基于Web的宠物店信息管理系统设计[J]. 软件, 2023(2):147-149.
+[5] 艾钰承, 朱海风, 刘舟. 基于SpringBoot的“喵站”宠物服务平台的设计与实现[J]. 科技资讯, 2023(22):22-25.
+[6] 庞嵩昊, 李盈, 赵艺, 等. 基于Vue和SpringBoot前后端分离的宠物服务系统设计与实现[J]. 电脑知识与技术, 2023(21):42-45.
+[7] 丁禹钧, 朱一龙, 王雪静. 基于SpringBoot和Vue的管理系统设计[J]. 电脑编程技巧与维护, 2025(9):110-112.
+[8] 柳伟卫. Vue.js+Spring Boot全栈开发实战[M]. 北京: 人民邮电出版社, 2023.
+
+## 致谢
+
+在本次毕业设计与论文撰写过程中，感谢指导教师在选题论证、系统设计、论文结构与表达规范等方面提供的持续指导。感谢学院和专业课程体系为本课题提供的理论基础与实践环境。感谢同学与朋友在测试反馈与资料收集过程中的帮助。最后，感谢家人对本人学习与毕业设计工作的支持与鼓励。
+
+## 附录
+
+### 附录A 缩略语说明
+
+| 缩略语 | 英文全称 | 中文说明 |
+|---|---|---|
+| RBAC | Role-Based Access Control | 基于角色的访问控制 |
+| JWT | JSON Web Token | 用于无状态认证的令牌机制 |
+| CRUD | Create, Read, Update, Delete | 增删改查基础数据操作 |
+| API | Application Programming Interface | 应用程序接口 |
+
+### 附录B 论文图表清单索引说明
+
+本文第3章与第4章涉及用例图、功能结构图、类图、序列图、活动图、E-R图及界面设计图，图号已按章节顺序编排。第5章与第6章运行截图及测试截图可在系统最终验收阶段补充为正式附图。
diff --git a/爱维宠物医院管理系统毕业论文-含图表版.docx b/爱维宠物医院管理系统毕业论文-含图表版.docx
deleted file mode 100644
index 5ae64cf..0000000
Binary files a/爱维宠物医院管理系统毕业论文-含图表版.docx and /dev/null differ
diff --git a/爱维宠物医院管理系统毕业论文-正确转换版.docx b/爱维宠物医院管理系统毕业论文-正确转换版.docx
deleted file mode 100644
index 2e8fa41..0000000
Binary files a/爱维宠物医院管理系统毕业论文-正确转换版.docx and /dev/null differ
diff --git a/爱维宠物医院管理系统毕业论文-由markdown转换版.docx b/爱维宠物医院管理系统毕业论文-由markdown转换版.docx
deleted file mode 100644
index 2cf81b2..0000000
Binary files a/爱维宠物医院管理系统毕业论文-由markdown转换版.docx and /dev/null differ