企业官网建设流程全解析

简介：这是一份面向Python初学者及小型财务管理需求的简易记账软件设计源码，结合Python后端与HTML/CSS/JavaScript前端，提供收支记录、订单管理等基础功能，适用于个人或小型企业的日常记账场景。压缩包共包含37个文件，其中以20个Python脚本为核心，涵盖控制层、数据访问层与业务逻辑层；另有5个JavaScript和4个CSS/HTML文件用于构建交互界面，其余包括配置文件、图标及说明文档，整体大小仅848KB，结构清晰、便于上手。资源已吸引720人学习，源码采用分层设计，controller、dao、service目录划分明确，可作为理解软件分层架构的入门范例。通过学习可得完整的记账应用实现，包括用户与订单管理、界面布局与动态交互，以及Git忽略规则等工程细节，既能直接运行体验，也能作为二次开发的起点。

1. 简易记账软件源码，为什么值得自己动手写一遍

翻遍手机支付账单，月底还是说不清钱花到了哪；想记账，Excel 太重，商业 App 又担心数据传上云端。基于 Python 的简易记账软件，正好卡在这个需求上：一个本地 SQLite 文件存账目，几条命令行记收支，一个脚本画趋势图。源码看着小，却完整覆盖了数据结构、数据库持久化、CLI 交互、统计报表和单元测试，适合刚学完 Python 基础、想练完整项目的开发者，也适合想搭不上云账本的一线工程师。下面按落地顺序拆开讲：先立数据模型，再串命令行，最后补测试和进阶功能，并把最容易翻车的五个坑单独拎出来。

2. 记账核心模型设计与 SQLite 存储：先定数据结构再写业务

写记账软件最怕什么？不是功能少，而是一上来就写界面、写业务，数据结构随手定义，等做到统计报表那一步才发现分类存得乱、金额精度对不上，只能回头重构。我的习惯是反过来：先把账目当成一个数据库问题来设计，模型立住了，后面的命令行、报表、测试全是顺水推舟。

2.1 收支两条线的数据模型：类型、金额、日期一个都不能少

一笔账需要记哪些信息？我一般会收敛成五个字段：收支类型、金额、分类、日期、备注。类型只有收入和支出两种，用带 CHECK 约束的 TEXT 字段比自由字符串靠谱，避免有人填了"收入"有人填了"入账"，统计时 GROUP BY 出来一堆同义分类。金额这里先按下不表，但你要知道它必须单独用一个字段存，因为后面所有统计都建立在它上面，float 精度问题会在第 4 章单独展开。

存储选 SQLite 而不是 JSON 或 CSV，原因很实际：sqlite3 是 Python 标准库自带的，不用装数据库服务；单文件存储，备份就是拷一个文件；支持 SQL 聚合查询，做月度统计时不用把整个文件读进内存手写循环。JSON 和 CSV 方案在小规模下也能跑，一旦账目到几千条，每次统计要全量读文件、并发写还可能损坏数据，SQLite 的成熟度明显高一个量级。

2.2 建表 SQL 与初始化脚本：第一次运行自动建库

数据访问层我习惯单独放一个 storage.py，业务逻辑不直接碰 SQL。先看建表和初始化：

# storage.py import sqlite3 from pathlib import Path # 数据库放在用户主目录下，而不是源码目录 # 这样换目录、换虚拟环境、换机器都不会影响已有数据 DB_PATH = Path.home() / "ledger_data" / "ledger.db" def get_conn(): conn = sqlite3.connect(DB_PATH) # 让查询结果能用字段名访问，而不是按下标取 conn.row_factory = sqlite3.Row return conn def init_db(): """首次运行时建库建表，重复执行不会破坏已有数据""" DB_PATH.parent.mkdir(parents=True, exist_ok=True) conn = get_conn() conn.executescript(""" CREATE TABLE IF NOT EXISTS transactions ( id INTEGER PRIMARY KEY AUTOINCREMENT, tx_type TEXT NOT NULL CHECK (tx_type IN ('income', 'expense')), amount_cents INTEGER NOT NULL CHECK (amount_cents >= 0), category TEXT NOT NULL, tx_date TEXT NOT NULL, note TEXT DEFAULT '' ); CREATE INDEX IF NOT EXISTS idx_tx_date ON transactions(tx_date); """) conn.commit() conn.close()

这段代码的四个关键点：第一，DB_PATH.parent.mkdir保证目录不存在时自动创建，用户拿到源码第一次运行就能直接建库；第二，IF NOT EXISTS让脚本可以重复执行，不会因为二次初始化清掉数据；第三，amount_cents用整数存"分"，这是给精度问题上的保险，后面会详细说；第四，日期字段上建索引，按月查询走索引，账目多了以后 list 和统计不会被全表扫描拖慢。

字段设计对应关系如下表：

提示：数据库文件放用户主目录而不是源码目录，是为了让换目录、换虚拟环境都不丢数据。这个点第 4 章会专门展开。

2.3 数据访问层封装：增删改查四个基础方法与参数说明

建表只是第一步，接下来封装增删改查。所有 SQL 都用参数化占位符，绝不把用户输入拼进 SQL 字符串，这是记账类工具不能破的底线，既防 SQL 注入也防引号转义问题。

# storage.py 续 def add_transaction(tx_type, amount_yuan, category, tx_date, note=""): """新增一笔账，金额以元传入，内部转成分为整数存储""" if tx_type not in ("income", "expense"): raise ValueError("tx_type 只能是 income 或 expense") amount_cents = int(round(amount_yuan * 100)) conn = get_conn() conn.execute( "INSERT INTO transactions (tx_type, amount_cents, category, tx_date, note)" " VALUES (?, ?, ?, ?, ?)", (tx_type, amount_cents, category, tx_date, note), ) conn.commit() conn.close() def list_by_month(year, month): """查询某月的全部账目，按日期排序""" conn = get_conn() rows = conn.execute( "SELECT id, tx_type, amount_cents, category, tx_date, note" " FROM transactions" " WHERE tx_date LIKE ?" " ORDER BY tx_date", (f"{year}-{month:02d}-%",), ).fetchall() conn.close() return rows def delete_transaction(tx_id): """按 id 删除一笔账，返回是否真的删到了""" conn = get_conn() cur = conn.execute("DELETE FROM transactions WHERE id = ?", (tx_id,)) conn.commit() conn.close() return cur.rowcount > 0

add_transaction的参数值得逐个说：amount_yuan以元为单位传入，函数内部做int(round(... * 100))转成分，这样调用方不需要关心精度；tx_date由调用方传入 ISO 格式字符串，默认值逻辑放在命令行层，数据层不感知"今天"这个概念。list_by_month用LIKE '2025-06-%'匹配月份，比strftime函数更直观，配合日期索引在数据量大时依然够快。delete_transaction返回rowcount，上层可以判断 id 是否真实存在，避免删了个寂寞还提示成功。

3. 命令行主流程与报表输出：把记账源码做成每天真会用的工具

数据模型定了，工具能不能每天用起来，取决于交互顺不顺手。对本地记账工具来说，命令行天然比 GUI 合适：启动快、可脚本化、能配合定时任务。这章用 argparse 把"记一笔、查账、统计、画图"串成四个子命令，让源码从"能存"做到"能看"。

3.1 argparse 子命令解析：add、list、summary 怎么串起来

argparse 的add_subparsers是把多个命令组织进一个程序的标准做法，比手写 if/elif 判断sys.argv清晰得多。入口文件 ledger.py 的骨架如下：

# ledger.py import argparse from datetime import date import storage def cmd_add(args): storage.add_transaction( args.type, args.amount, args.category, args.date or date.today().isoformat(), args.note, ) print(f"已记录：{args.type} {args.amount:.2f} 元，分类：{args.category}") def cmd_list(args): rows = storage.list_by_month(args.year, args.month) for r in rows: yuan = r["amount_cents"] / 100 tag = "收" if r["tx_type"] == "income" else "支" print(f"{r['tx_date']} {tag} {yuan:>8.2f} {r['category']:<4s} {r['note']}") def build_parser(): parser = argparse.ArgumentParser(description="简易记账软件") sub = parser.add_subparsers(dest="command", required=True) p_add = sub.add_parser("add", help="记一笔账") p_add.add_argument("--type", choices=["income", "expense"], required=True) p_add.add_argument("--amount", type=float, required=True) p_add.add_argument("--category", required=True) p_add.add_argument("--date", default=None, help="默认今天，格式 YYYY-MM-DD") p_add.add_argument("--note", default="", help="备注") p_add.set_defaults(func=cmd_add) p_list = sub.add_parser("list", help="查某月账单") p_list.add_argument("--year", type=int, default=date.today().year) p_list.add_argument("--month", type=int, default=date.today().month) p_list.set_defaults(func=cmd_list) return parser def main(): args = build_parser().parse_args() args.func(args) if __name__ == "__main__": main()

这套设计里，参数定义和命令处理是解耦的：每个子命令把自己的参数注册好，再用set_defaults(func=...)绑定处理函数，main里一行args.func(args)就完成了分发，以后加新命令只需要加一个cmd_xxx函数和一个子解析器。choices让工具在参数阶段就拦截非法收支类型，比进了数据层再抛 ValueError 体验好。--date默认 None，处理函数里用or date.today().isoformat()兜底，保证--date传了就用传入值，没传就用今天，逻辑一目了然。

实际使用时的命令长这样：

# 首次运行前先初始化数据库（脚本里会自动建库） python ledger.py add --type expense --amount 35.5 --category 餐饮 --note 午餐 python ledger.py add --type income --amount 8500 --category 工资 python ledger.py list --year 2025 --month 6 python ledger.py summary --year 2025 --month 6

list和summary的--year、--month默认取当前年月，平时查当月账直接python ledger.py list就行，只有翻旧账时才需要显式传参。注意add里--amount用 float 接收是没问题的，因为精度转换发生在storage.add_transaction内部，数据层守住整数底线即可。

3.2 月度分类汇总：用一条 GROUP BY 替代手写循环

月度汇总是最常用的统计需求：这个月餐饮花了多少、交通花了多少、总共支出多少。新手容易在 Python 里遍历所有账目累加，账目一多就慢且代码啰嗦。正确做法是把聚合交给 SQLite：

# storage.py 续 def summary_by_month(year, month): """按分类汇总某月收支，金额单位分，按汇总金额倒序""" conn = get_conn() rows = conn.execute( """ SELECT category, tx_type, SUM(amount_cents) AS total_cents FROM transactions WHERE tx_date LIKE ? GROUP BY category, tx_type ORDER BY total_cents DESC """, (f"{year}-{month:02d}-%",), ).fetchall() conn.close() return rows

这条 SQL 干了三件事：WHERE先用 LIKE 圈定月份，GROUP BY category, tx_type把同分类同类型的行合并，SUM算总额。把分类和类型一起分组，是因为同名的"工资收入"和"餐饮支出"不该混在一个桶里。ORDER BY total_cents DESC让花得最多的分类排最前，命令行打印时一眼看到大额支出在哪里。相比 Python 循环，这条 SQL 在万级数据量下依然是毫秒级，而且语义直接。

对应的命令行汇总结果可以做成对齐的简单表格：

# ledger.py 续 def cmd_summary(args): rows = storage.summary_by_month(args.year, args.month) print("分类 金额(元)") print("-" * 30) total = 0 for r in rows: yuan = r["total_cents"] / 100 total += yuan print(f"{r['category']:<10s} {yuan:>8.2f}") print("-" * 30) print(f"合计 {total:.2f}")

cmd_summary在 Python 侧只做两件事：把分转成元、拼成对齐文本。真正的数据加工全在 SQL 里完成，职责很干净。

3.3 matplotlib 画月度支出趋势图：参数就调四个

看趋势比看数字更直观。给工具加一个chart子命令，用 matplotlib 输出月度支出柱状图，代码不长但覆盖了一个完整的数据到可视化链路：

# stats.py import matplotlib.pyplot as plt import storage def plot_monthly_expense(year): """画某年 1-12 月支出柱状图并保存为 PNG""" conn = storage.get_conn() rows = conn.execute( """ SELECT substr(tx_date, 1, 7) AS month, SUM(amount_cents) AS total_cents FROM transactions WHERE tx_type = 'expense' AND tx_date LIKE ? GROUP BY substr(tx_date, 1, 7) ORDER BY month """, (f"{year}-%",), ).fetchall() conn.close() months = [r["month"] for r in rows] expenses = [r["total_cents"] / 100 for r in rows] plt.figure(figsize=(10, 5)) plt.bar(months, expenses, color="#4C7A9D") plt.title(f"{year} 年每月支出") plt.xlabel("月份") plt.ylabel("支出（元）") plt.xticks(rotation=45) plt.tight_layout() plt.savefig(f"expense_{year}.png", dpi=150)

substr(tx_date, 1, 7)把2025-06-03截成2025-06，直接在 SQL 里完成按月归组，避免把全部数据拉回 Python 再处理。图表参数真正需要调的只有四个：figsize控制画布宽高、xticks(rotation=45)防止月份标签重叠、tight_layout()修边距、savefig的dpi决定清晰度。在 ledger.py 里加一个chart子命令调用这个函数，python ledger.py chart --year 2025就能在项目目录生成一张 PNG。工具做到这一步已经具备实用价值。

4. 记账软件避坑指南：从 float 精度到中文路径的 5 个翻车现场

数据模型和命令都跑通了，接下来是血泪经验集中区。这五个坑我帮 A同学 review 代码时反复见到，前三个是逻辑错误，后两个是工程习惯问题，每一个都真实到能让你对着屏幕怀疑人生。

4.1 金额用 float 存，月底对账对不上

现象：记了 100 笔 0.1 元的账，统计出来不是 10.00 元而是 9.999999999999998，对账怎么都对不平。

原因：二进制浮点数无法精确表示 0.1，0.1 + 0.2在 Python 里等于0.30000000000000004。这不是 Python 的 bug，是 IEEE 754 的固有特性，看着像玄学，实际是确定的精度损失。记账软件里金额是核心数据，任何一元钱的误差都不能接受。

解决：存储层一律用整数"分"，只在输入和输出时做元与分的换算。

# 错误：直接存 float amount = 0.1 + 0.2 # 0.30000000000000004 # 正确：内部转分为整数，展示时才除回元 amount_cents = int(round(35.5 * 100)) # 3550

注意round在这里不能省，35.5 * 100在浮点运算下可能得到3549.9999999999995，直接int()截断会丢一分钱。先round再int是标准姿势。

4.2 日期格式不统一，排序和按月查询全乱

现象：同一天的账有的存2025/6/3，有的存2025-06-03，还有存6月3日的，list 排序时 6/30 排在 7/1 后面，按月查询LIKE '2025-06-%'匹配不到任何记录。

原因：日期是字符串存储的，字符串排序靠的是字典序。2025/6/3和2025-06-03的字典序完全不同，SQL 的ORDER BY和LIKE都依赖格式一致。

解决：约定唯一格式YYYY-MM-DD，在命令行入口把所有输入日期统一格式化，数据层绝不存第二种格式。

# 统一入口：add 命令里把各种输入转成 ISO 格式 # 伪代码示意 if re.match(r"^\d{4}-\d{2}-\d{2}$", raw_date): tx_date = raw_date else: raise ValueError("日期格式必须为 YYYY-MM-DD")

一个更省心的做法是命令行不接受自由日期，--date只接受 ISO 格式或留空取今天，从源头消灭格式分叉。

4.3 中文路径 + Windows 编码，数据库打不开

现象：在 Windows 上运行，代码在C:\Users\张三\Documents\ledger\目录下，sqlite3.connect直接抛OperationalError: unable to open database file，但同样的代码在纯英文路径下一切正常。

原因：数据库路径本身包含中文，部分 Windows 环境下的文件系统调用和 Python 字符串编码处理不一致，尤其当路径是手工用字符串拼接出来时，最容易触发问题。

解决：用pathlib.Path构建路径，它对编码的处理比裸字符串可靠得多，并且跨平台一致。

# 错误：手工拼接字符串路径 db_path = "C:\\Users\\张三\\Documents\\" + "ledger.db" # 正确：pathlib 统一处理 from pathlib import Path DB_PATH = Path.home() / "ledger_data" / "ledger.db"

Path.home()返回用户主目录对象，/运算符拼接子路径，不涉及手工处理分隔符和编码，Windows、macOS、Linux 三端行为一致。这也是上一章把数据库放到主目录而不是源码目录的原因之一。

4.4 误删一条账目，没有后悔药

现象：删除一笔账后才发现记错了月份或者金额，想去数据库里捞回来，发现 DELETE 已经把数据物理删掉了，SQLite 没有自带回收站。

原因：设计时只考虑了"能删"，没考虑"删错了怎么办"。本地工具没有服务端审计日志，一旦删除就是不可逆操作。

解决：删除前自动备份数据库文件，或者干脆用软删除标记。备份方案成本最低：

# 删除前自动备份（伪代码） import shutil from datetime import datetime if DB_PATH.exists(): backup = DB_PATH.with_name( f"ledger_{datetime.now():%Y%m%d_%H%M%S}.db" ) shutil.copy2(DB_PATH, backup)

拷贝发生在每次删除操作之前，备份文件名带时间戳，想恢复就找到对应时间点的备份文件，重命名回ledger.db。软删除则是加一个deleted字段，查询时过滤，代价是每条查询都要带条件，对小工具来说备份方案更简单直接。

4.5 数据库路径写死，换个目录数据"丢"了

现象：在源码目录下运行，记了几百笔账，第二天把项目文件夹挪了个位置再运行，账目全没了，吓得以为数据被清空。

原因：数据库路径写成了相对路径"./ledger.db"，SQLite 会在当前工作目录建文件。python ledger.py list从哪个目录执行，它就找哪个目录下的ledger.db，换目录等于换库。

解决：数据库路径锚定到用户主目录，或者用环境变量覆盖：

# 错误：相对路径，执行目录一变数据就'丢' DB_PATH = "./ledger.db" # 正确：锚定用户目录，并允许环境变量覆盖 import os DB_PATH = Path(os.environ.get("LEDGER_DB", Path.home() / "ledger_data" / "ledger.db"))

LEDGER_DB环境变量是给高级用户留的口子，默认值保证绝大多数场景行为一致。记住一个原则：用户数据目录和代码目录必须分开，代码可以被删除重装，数据不能跟着一起陪葬。

5. 让源码 3 分钟可复现：项目结构、requirements 与核心测试

一个源码能不能被称作"完整交付物"，看的不只是功能跑通，还有别人拿到手能不能快速跑起来、改完代码有没有安全感。这章把项目结构、依赖管理和单元测试补齐，让这份记账软件源码达到可复现、可维护的标准。

5.1 源码包的标准项目结构：每个文件的职责一张表说清

我一般把小型 Python 工具按"入口、数据层、统计层、测试"四个维度组织文件，互不嵌套。这个记账项目最终结构如下：

ledger.py只做参数解析和调用，storage.py只做数据库读写，stats.py只做图表，三者通过函数调用耦合，不共享全局状态。这个分层在项目长大后能平滑扩展：想加 Web 界面，直接在新层里调用storage的函数，不需要动数据层。

5.2 requirements.txt 加虚拟环境：别人 clone 下来三分钟跑起来

很多人忽视依赖管理，直接在系统 Python 里pip install，后果是换台机器跑不起来、版本冲突查半天。标准做法是虚拟环境加依赖清单：

# 创建并激活虚拟环境 python -m venv .venv source .venv/bin/activate # Windows 下用 .venv\Scripts\activate # 安装依赖 pip install -r requirements.txt

requirements.txt 内容极简，因为 sqlite3、argparse、pathlib 都是 Python 标准库，不需要列：

matplotlib>=3.7 pytest>=7.0

matplotlib>=3.7这个下限是我常用的保守写法：低于 3.7 的版本在部分中文字体渲染上有兼容问题，画图标题会变成方格；pytest>=7.0则是当前生态的事实标准，支持tmp_path和monkeypatch这两个测试必备 fixture。依赖尽量少，是本地小工具最重要的可维护性指标，每多一个第三方包就多一个版本冲突的来源。

5.3 pytest 三个断言：把金额精度和按月过滤锁死在测试里

没有测试的记账源码，每次改动都像在黑匣子上打补丁。用 pytest 给数据层写三个核心测试，覆盖最容易被改坏的逻辑：

# tests/test_ledger.py import storage def test_add_amount_stored_as_cents(tmp_path, monkeypatch): # 把数据库指向临时目录，避免污染真实数据 monkeypatch.setattr(storage, "DB_PATH", tmp_path / "t.db") storage.init_db() storage.add_transaction("expense", 35.5, "餐饮", "2025-06-01") rows = storage.list_by_month(2025, 6) assert len(rows) == 1 assert rows[0]["amount_cents"] == 3550 def test_list_by_month_filters_correctly(tmp_path, monkeypatch): monkeypatch.setattr(storage, "DB_PATH", tmp_path / "t.db") storage.init_db() storage.add_transaction("expense", 10, "交通", "2025-06-01") storage.add_transaction("expense", 20, "交通", "2025-07-01") rows = storage.list_by_month(2025, 6) assert len(rows) == 1 def test_summary_groups_by_category(tmp_path, monkeypatch): monkeypatch.setattr(storage, "DB_PATH", tmp_path / "t.db") storage.init_db() storage.add_transaction("expense", 10, "餐饮", "2025-06-01") storage.add_transaction("expense", 5, "餐饮", "2025-06-02") storage.add_transaction("expense", 3, "交通", "2025-06-03") summary = storage.summary_by_month(2025, 6) by_cat = {r["category"]: r["total_cents"] for r in summary} assert by_cat["餐饮"] == 1500 assert by_cat["交通"] == 300

三个测试分别锁住三件事：金额转分的精度、按月过滤的边界、分类汇总的正确性。monkeypatch.setattr把DB_PATH临时指向 pytest 提供的tmp_path，测试跑完数据自动清理，不会在你真实的账本里留下垃圾数据。以后任何人重构storage.py，跑一遍pytest tests/就能确认统计逻辑没有被改坏。代码量不大，但它是这份源码从"自己写着玩"变成"可以交给别人维护"的分水岭。

6. 进阶技巧：给记账源码加一个月度预算超支提醒

记账工具的真正价值，是从"记录"变成"约束"。有一个门槛最低、每天都能用上的功能：月度预算提醒。记录支出时顺手算一下当月累计，快超预算就提示一声，不打断操作也不强制拦截。实现只需要一张设置表和一次额外查询：

# storage.py 补充 def get_budget(conn): """从设置表读月度预算，没设置过就给默认值 3000""" row = conn.execute( "SELECT value FROM settings WHERE key = 'monthly_budget'" ).fetchone() return int(row["value"]) if row else 3000 def month_expense_total(conn, year, month): """当月累计支出，单位元""" row = conn.execute( """ SELECT COALESCE(SUM(amount_cents), 0) AS total_cents FROM transactions WHERE tx_type = 'expense' AND tx_date LIKE ? """, (f"{year}-{month:02d}-%",), ).fetchone() return row["total_cents"] / 100

建表语句里补一张settings表，一个key-value结构就够用。然后在cmd_add里，记完支出后追加一段检查逻辑：当月累计加上这笔新支出，超过预算就打印醒目的提示，但绝不阻止记账。这个设计刻意把"提醒"和"拦截"分开，记账工具的底线是记录必须完整，拦截会诱导用户绕过工具去记别的账。预算值我没有固化在代码里，而是通过设置表可改，后续加一个set-budget子命令只是几行代码的事。

这个方向值不值得投入，我的判断是值得，但要把边界想清楚：它不打算替代专业财务软件，账目抓取、多账本、报表导出这些重需求不适合往这个小工具里塞。它最合适的定位是个人本地账本、Python 练手的完整闭环、以及后续想学 Web 后端时直接套用的数据层底座。我自己维护这类工具的习惯是守三条底线：数据文件永远可拷贝、命令永远可重放、所有统计逻辑永远有测试兜底。预算提醒就是在这条线上长出来的第一个功能，你完全可以照着同样的思路继续加：按分类设限额、月末自动导出 CSV、甚至把 SQLite 文件同步到网盘。希望帮到你。

本文还有配套的精品资源，点击获取