雅兰辅助实战项目：3步搞定报错，避开90%新手坑
报错一堆看不懂 StackTrace，直接卡死在雅兰辅助的实战项目里？别慌，这太正常了。很多刚接触水利信息化或自动化辅助工具的朋友，一看到满屏红色堆栈信息就头大。其实，雅兰辅助这类工具的核心逻辑并不复杂，难的是环境配置和异常处理。
咱们今天不整虚的，直接上干货。这篇文章就是为了解决你“报错看不懂”、“代码跑不通”、“实战项目无从下手”这三个大痛点。我会带你从零搭建一个基于 Python 的雅兰辅助数据处理原型，覆盖从目录结构到核心代码，再到运行测试和扩展优化。
读完这篇，你手里会有一个能跑通的最小化实战项目，并且知道当 StackTrace 再次出现时，该看哪一行，该改哪里。
项目目标与场景拆解
在动手写代码前，先搞清楚我们要做什么。雅兰辅助在这里不仅仅是一个名字，它代表了一套针对水利数据（如水位、流量、降雨量）进行预处理、校验和格式转换的辅助流程。
核心痛点场景：
想象一下，你从前端或者传感器拿到的原始数据是一团乱麻：单位不统一（有的米，有的厘米），时间戳格式混乱（有的是 ISO8601，有的是 Unix 时间戳），甚至夹杂着空值和非法字符。直接入库？数据库直接炸给你看。直接给前端？前端报错一片。
本项目目标：数据清洗：自动识别并修正单位、时间格式。
异常捕获：遇到脏数据不崩溃，而是记录日志并跳过，或者给出明确提示。
结构化输出：生成标准的 JSON 或 CSV 文件，供后续业务系统使用。为什么选 Python？
因为 Python 的 pandas 和 datetime 库处理这类结构化数据简直是降维打击。而且，Python 的错误堆栈（StackTrace）虽然长，但只要掌握了阅读技巧，定位问题非常快。这也是我们今天要重点突破的难点。
目录结构规划
一个合格的实战项目，目录结构必须清晰。别把所有代码都塞在 main.py 里，那样等你代码量上来，自己都会找不到北。
我们采用如下结构：
yilan-helper/
├── main.py # 入口文件
├── config.yaml # 配置文件（定义单位、路径等）
├── requirements.txt # 依赖包
├── src/
│ ├── __init__.py
│ ├── parser.py # 数据解析模块
│ ├── cleaner.py # 数据清洗模块
│ └── utils.py # 通用工具函数（日志、文件操作）
├── data/
│ ├── raw/ # 原始数据存放地
│ └── output/ # 处理后的数据输出地
└── logs/└── app.log # 运行日志关键点讲解：config.yaml：把硬编码的配置抽离出来。比如“默认单位是米”、“数据源路径是哪里”，都放在这里。以后换项目，改配置文件就行，不用动代码。
src 分层：parser 负责把字符串变成对象，cleaner 负责修脏数据。职责分离，以后要是解析逻辑变了，只改 parser.py，不影响其他部分。
logs：这是解决“报错看不懂”的神器。把详细的错误信息写进日志文件，而不是只在控制台闪一下。核心代码实现与逐行解析
现在进入正题。我们不看复杂的框架，就用最基础的逻辑，把“雅兰辅助”的核心功能实现出来。
1. 初始化与配置加载
首先，我们在 main.py 中初始化项目。这里我们引入 yaml 库来读取配置。
import yaml
import logging
from src.parser import DataParser
from src.cleaner import DataCleanerdef setup_logger():# 配置日志，关键！logging.basicConfig(level=logging.INFO,format='%(asctime)s - %(levelname)s - %(message)s',handlers=[logging.FileHandler(logs/app.log),logging.StreamHandler()])return logging.getLogger(__name__)def load_config(path='config.yaml'):with open(path, 'r', encoding='utf-8') as f:return yaml.safe_load(f)if __name__ == '__main__':logger = setup_logger()config = load_config()# 实例化解析器和清洗器parser = DataParser(config)cleaner = DataCleaner(config)# 执行主流程try:raw_data = parser.read_raw_file('data/raw/sample_data.csv')cleaned_data = cleaner.process(raw_data)cleaner.save_output(cleaned_data, 'data/output/cleaned_data.json')logger.info(数据处理成功完成)except Exception as e:# 捕获所有未预见的异常logger.error(f发生未知错误: {e}, exc_info=True)raise逐行解析重点：logging.basicConfig：注意 exc_info=True。这是解决 StackTrace 看不懂的第一把钥匙。加上这个参数，当异常发生时，日志里会打印完整的调用栈，而不只是一行错误信息。
try...except：永远不要裸奔。在实战项目中，任何 I/O 操作（读文件、写文件、网络请求）都可能失败。except 块里记录日志，然后重新抛出或优雅退出。2. 数据解析模块 (parser.py)
假设原始数据是一个 CSV 文件，每行包含：timestamp, value, unit。
import pandas as pd
import datetimeclass DataParser:def __init__(self, config):self.config = configself.default_unit = config.get('default_unit', 'm')def read_raw_file(self, file_path):读取原始 CSV 文件try:# 使用 pandas 读取，指定分隔符df = pd.read_csv(file_path, header=None, names=['ts', 'val', 'unit'])return dfexcept FileNotFoundError:raise FileNotFoundError(f找不到文件: {file_path})except pd.errors.ParserError as e:raise ValueError(fCSV 解析失败，格式错误: {e})def parse_timestamp(self, ts_str):尝试多种格式解析时间戳formats = ['%Y-%m-%d %H:%M:%S', '%Y/%m/%d %H:%M', '%s'] # 支持ISO和Unix时间戳for fmt in formats:try:if fmt == '%s':return datetime.datetime.fromtimestamp(int(ts_str))else:return datetime.datetime.strptime(ts_str, fmt)except ValueError:continuereturn None避坑指南：时间格式兼容：实战中，时间格式是最容易出错的。不要假设输入一定是某种格式。写一个循环尝试多种格式，失败就返回 None，让后续的清洗器去处理。
异常细分：FileNotFoundError 和 ParserError 是两种完全不同的问题。前者是路径错了，后者是数据格式乱了。分开捕获，日志里写清楚原因，你就知道该怎么修了。3. 数据清洗模块 (cleaner.py)
这是“雅兰辅助”的核心。我们要处理单位换算、空值填充等。
import json
import logginglogger = logging.getLogger(__name__)class DataCleaner:def __init__(self, config):self.config = config# 单位换算因子，目标单位统一为 'm'self.unit_factors = {'m': 1,'cm': 0.01,'mm': 0.001,'ft': 0.3048}def process(self, df):主清洗逻辑results = []for index, row in df.iterrows():try:# 1. 解析时间dt = self.parse_ts(row['ts'])if dt is None:logger.warning(f行 {index}: 时间解析失败, 跳过. 原始值: {row['ts']})continue# 2. 解析数值val = float(row['val'])# 3. 单位换算unit = str(row['unit']).strip().lower()if unit not in self.unit_factors:logger.warning(f行 {index}: 未知单位 '{unit}', 使用默认单位. 原始值: {row['val']})# 策略：未知单位按默认单位处理，或者报错，这里选择宽容模式unit = self.config.get('default_unit', 'm')val = val * self.unit_factors[unit]# 4. 构建结果对象results.append({'timestamp': dt.isoformat(),'value': round(val, 4),'original_unit': unit})except (ValueError, TypeError) as e:# 捕获数值转换错误logger.error(f行 {index}: 数值转换失败. 原始数据: {row.to_dict()}, 错误: {e})continueexcept Exception as e:# 捕获其他意外错误logger.error(f行 {index}: 发生未知错误. {e}, exc_info=True)continuereturn resultsdef parse_ts(self, ts_str):# 简化版时间解析，实际项目中可复用 parser 中的逻辑try:return datetime.datetime.fromisoformat(ts_str)except:try:return datetime.datetime.fromtimestamp(int(ts_str))except:return Nonedef save_output(self, data, file_path):try:with open(file_path, 'w', encoding='utf-8') as f:json.dump(data, f, indent=2, ensure_ascii=False)logger.info(f数据已保存至: {file_path})except IOError as e:logger.error(f文件写入失败: {e})深度解析：宽容模式 vs 严格模式：在 process 方法中，遇到未知单位，我选择了“使用默认单位”并记录 warning。如果你的业务要求极高，这里应该 raise 异常。这是架构设计的选择，需要根据业务场景定。
exc_info=True 再次出现：在 except Exception 中，我们再次使用了 exc_info=True。当你看到日志里出现 Traceback (most recent call last): 后面跟着一堆文件行号时，不要慌。看最后一行，那是真正报错的地方。往上看，找到你代码里的那一行，问题就在那。运行与测试：如何看懂 StackTrace
代码写完了，怎么跑？怎么测？
1. 准备测试数据
在 data/raw/sample_data.csv 中放入几行脏数据：
2023-10-01 10:00:00, 1.5, m
2023-10-01 10:01:00, 150, cm
invalid_time, 2.0, m
2023-10-01 10:03:00, abc, m
2023-10-01 10:04:00, 3.0, unknown_unit2. 安装依赖
pip install pandas pyyaml3. 运行并观察日志
执行 python main.py。
场景一：时间解析失败
日志输出：
WARNING - 行 2: 时间解析失败, 跳过. 原始值: invalid_time
分析：这是预期行为。parser 或 cleaner 捕获了 ValueError，记录了 warning，跳过了该行。程序没有崩溃。这就是健壮的代码。
场景二：数值转换失败
日志输出：
ERROR - 行 3: 数值转换失败. 原始数据: {'ts': '2023-10-01 10:03:00', 'val': 'abc', 'unit': 'm'}, 错误: could not convert string to float: 'abc'
分析：float('abc') 抛出 ValueError。我们捕获了它，并打印了原始数据。现在你知道哪一行数据坏了，去源头修正数据即可。
场景三：真正的 Bug（模拟）
假设你在 cleaner.py 中写错了一个变量名，比如 self.unit_factors 写成了 self.unit_factor。
日志输出：
ERROR - 行 0: 发生未知错误. 'DataCleaner' object has no attribute 'unit_factor'
Traceback (most recent call last):File main.py, line 28, in modulecleaned_data = cleaner.process(raw_data)File src/cleaner.py, line 32, in processval = val * self.unit_factors[unit]
AttributeError: 'DataCleaner' object has no attribute 'unit_factor'如何解读？看最后一行：AttributeError: ... no attribute 'unit_factor'。告诉你属性名错了。
看堆栈：File src/cleaner.py, line 32。打开 cleaner.py，跳到第 32 行。
修正代码：把 unit_factor 改回 unit_factors。
重新运行。这就是 StackTrace 的正确打开方式。 不要试图读懂每一行库的代码，只看你自己代码所在的那一行和最后的那个错误类型。
优化扩展与工程化建议
当你的雅兰辅助项目跑通后，如何让它更专业？
1. 单元测试
别只用 print 调试。使用 pytest 写单元测试。
# test_cleaner.py
import pytest
from src.cleaner import DataCleaner
import pandas as pd@pytest.fixture
def cleaner():config = {'default_unit': 'm'}return DataCleaner(config)def test_unit_conversion(cleaner):df = pd.DataFrame({'ts': ['2023-01-01'], 'val': ['100'], 'unit': ['cm']})result = cleaner.process(df)assert result[0]['value'] == 1.0 # 100cm = 1m2. 性能优化
如果数据量达到百万级，df.iterrows() 会非常慢。优化方案：使用 pandas 的向量化操作。例如，df['value'] = df['value'].astype(float) * df['unit'].map(unit_factors)。这比循环快几个数量级。
参考：查阅 MDN Web Docs 中的性能相关文档虽然主要面向 JS，但其关于“避免在热路径中执行昂贵操作”的思想是通用的。在 Python 中，避免在循环内做字符串拼接、文件 I/O 等重操作。3. 配置外部化与 Docker 化将 config.yaml 通过环境变量注入，方便在不同环境（开发、测试、生产）切换。
编写 Dockerfile，将依赖打包。这样别人拉取你的代码，docker run 就能跑，解决了“在我电脑上能跑”的千古难题。4. 日志轮转
logs/app.log 会越来越大。使用 logging.handlers.RotatingFileHandler，每天或每 10MB 滚动一次日志，防止磁盘爆满。
小结与互动
今天我们从零搭建了一个雅兰辅助的实战项目原型。解决了：报错看不懂的问题，通过 logging 和 exc_info，你知道了 StackTrace 的读法。
实现了：数据清洗的核心逻辑，包括单位换算、时间解析、异常捕获。
规范了：项目目录结构和工程化流程，包括配置分离、日志记录、单元测试。编程不是为了写出最炫的代码，而是为了写出可维护、可调试、可复用的代码。当 StackTrace 再次出现时，希望你不再是那个被红色字体吓哭的新手，而是那个能精准定位问题的老手。
最后，抛出一个问题给大家讨论：
在实际的水利或 IoT 项目中，你们是如何处理“脏数据”的？是选择直接丢弃并报警，还是进行模糊匹配修正？或者你有更独特的处理策略？
你公司项目里是怎么处理的？欢迎在评论区分享你的踩坑经验和最佳实践。 雅兰辅助实战项目：3步搞定报错，避开90%新手坑
雅兰辅助实战项目：3步搞定报错，避开90%新手坑
报错一堆看不懂 StackTrace，直接卡死在雅兰辅助的实战项目里？别慌，这太正常了。很多刚接触水利信息化或自动化辅助工具的朋友，一看到满屏红色堆栈信息就头大。其实，雅兰辅助这类工具的核心逻辑并不复杂，难的是环境配置和异常处理。
咱们今天不整虚的，直接上干货。这篇文章就是为了解决你“报错看不懂”、“代码跑不通”、“实战项目无从下手”这三个大痛点。我会带你从零搭建一个基于 Python 的雅兰辅助数据处理原型，覆盖从目录结构到核心代码，再到运行测试和扩展优化。
读完这篇，你手里会有一个能跑通的最小化实战项目，并且知道当 StackTrace 再次出现时，该看哪一行，该改哪里。
项目目标与场景拆解
在动手写代码前，先搞清楚我们要做什么。雅兰辅助在这里不仅仅是一个名字，它代表了一套针对水利数据（如水位、流量、降雨量）进行预处理、校验和格式转换的辅助流程。
核心痛点场景：
想象一下，你从前端或者传感器拿到的原始数据是一团乱麻：单位不统一（有的米，有的厘米），时间戳格式混乱（有的是 ISO8601，有的是 Unix 时间戳），甚至夹杂着空值和非法字符。直接入库？数据库直接炸给你看。直接给前端？前端报错一片。
本项目目标：数据清洗：自动识别并修正单位、时间格式。
异常捕获：遇到脏数据不崩溃，而是记录日志并跳过，或者给出明确提示。
结构化输出：生成标准的 JSON 或 CSV 文件，供后续业务系统使用。为什么选 Python？
因为 Python 的 pandas 和 datetime 库处理这类结构化数据简直是降维打击。而且，Python 的错误堆栈（StackTrace）虽然长，但只要掌握了阅读技巧，定位问题非常快。这也是我们今天要重点突破的难点。
目录结构规划
一个合格的实战项目，目录结构必须清晰。别把所有代码都塞在 main.py 里，那样等你代码量上来，自己都会找不到北。
我们采用如下结构：
yilan-helper/
├── main.py # 入口文件
├── config.yaml # 配置文件（定义单位、路径等）
├── requirements.txt # 依赖包
├── src/
│ ├── __init__.py
│ ├── parser.py # 数据解析模块
│ ├── cleaner.py # 数据清洗模块
│ └── utils.py # 通用工具函数（日志、文件操作）
├── data/
│ ├── raw/ # 原始数据存放地
│ └── output/ # 处理后的数据输出地
└── logs/└── app.log # 运行日志关键点讲解：config.yaml：把硬编码的配置抽离出来。比如“默认单位是米”、“数据源路径是哪里”，都放在这里。以后换项目，改配置文件就行，不用动代码。
src 分层：parser 负责把字符串变成对象，cleaner 负责修脏数据。职责分离，以后要是解析逻辑变了，只改 parser.py，不影响其他部分。
logs：这是解决“报错看不懂”的神器。把详细的错误信息写进日志文件，而不是只在控制台闪一下。核心代码实现与逐行解析
现在进入正题。我们不看复杂的框架，就用最基础的逻辑，把“雅兰辅助”的核心功能实现出来。
1. 初始化与配置加载
首先，我们在 main.py 中初始化项目。这里我们引入 yaml 库来读取配置。
import yaml
import logging
from src.parser import DataParser
from src.cleaner import DataCleanerdef setup_logger():# 配置日志，关键！logging.basicConfig(level=logging.INFO,format='%(asctime)s - %(levelname)s - %(message)s',handlers=[logging.FileHandler(logs/app.log),logging.StreamHandler()])return logging.getLogger(__name__)def load_config(path='config.yaml'):with open(path, 'r', encoding='utf-8') as f:return yaml.safe_load(f)if __name__ == '__main__':logger = setup_logger()config = load_config()# 实例化解析器和清洗器parser = DataParser(config)cleaner = DataCleaner(config)# 执行主流程try:raw_data = parser.read_raw_file('data/raw/sample_data.csv')cleaned_data = cleaner.process(raw_data)cleaner.save_output(cleaned_data, 'data/output/cleaned_data.json')logger.info(数据处理成功完成)except Exception as e:# 捕获所有未预见的异常logger.error(f发生未知错误: {e}, exc_info=True)raise逐行解析重点：logging.basicConfig：注意 exc_info=True。这是解决 StackTrace 看不懂的第一把钥匙。加上这个参数，当异常发生时，日志里会打印完整的调用栈，而不只是一行错误信息。
try...except：永远不要裸奔。在实战项目中，任何 I/O 操作（读文件、写文件、网络请求）都可能失败。except 块里记录日志，然后重新抛出或优雅退出。2. 数据解析模块 (parser.py)
假设原始数据是一个 CSV 文件，每行包含：timestamp, value, unit。
import pandas as pd
import datetimeclass DataParser:def __init__(self, config):self.config = configself.default_unit = config.get('default_unit', 'm')def read_raw_file(self, file_path):读取原始 CSV 文件try:# 使用 pandas 读取，指定分隔符df = pd.read_csv(file_path, header=None, names=['ts', 'val', 'unit'])return dfexcept FileNotFoundError:raise FileNotFoundError(f找不到文件: {file_path})except pd.errors.ParserError as e:raise ValueError(fCSV 解析失败，格式错误: {e})def parse_timestamp(self, ts_str):尝试多种格式解析时间戳formats = ['%Y-%m-%d %H:%M:%S', '%Y/%m/%d %H:%M', '%s'] # 支持ISO和Unix时间戳for fmt in formats:try:if fmt == '%s':return datetime.datetime.fromtimestamp(int(ts_str))else:return datetime.datetime.strptime(ts_str, fmt)except ValueError:continuereturn None避坑指南：时间格式兼容：实战中，时间格式是最容易出错的。不要假设输入一定是某种格式。写一个循环尝试多种格式，失败就返回 None，让后续的清洗器去处理。
异常细分：FileNotFoundError 和 ParserError 是两种完全不同的问题。前者是路径错了，后者是数据格式乱了。分开捕获，日志里写清楚原因，你就知道该怎么修了。3. 数据清洗模块 (cleaner.py)
这是“雅兰辅助”的核心。我们要处理单位换算、空值填充等。
import json
import logginglogger = logging.getLogger(__name__)class DataCleaner:def __init__(self, config):self.config = config# 单位换算因子，目标单位统一为 'm'self.unit_factors = {'m': 1,'cm': 0.01,'mm': 0.001,'ft': 0.3048}def process(self, df):主清洗逻辑results = []for index, row in df.iterrows():try:# 1. 解析时间dt = self.parse_ts(row['ts'])if dt is None:logger.warning(f行 {index}: 时间解析失败, 跳过. 原始值: {row['ts']})continue# 2. 解析数值val = float(row['val'])# 3. 单位换算unit = str(row['unit']).strip().lower()if unit not in self.unit_factors:logger.warning(f行 {index}: 未知单位 '{unit}', 使用默认单位. 原始值: {row['val']})# 策略：未知单位按默认单位处理，或者报错，这里选择宽容模式unit = self.config.get('default_unit', 'm')val = val * self.unit_factors[unit]# 4. 构建结果对象results.append({'timestamp': dt.isoformat(),'value': round(val, 4),'original_unit': unit})except (ValueError, TypeError) as e:# 捕获数值转换错误logger.error(f行 {index}: 数值转换失败. 原始数据: {row.to_dict()}, 错误: {e})continueexcept Exception as e:# 捕获其他意外错误logger.error(f行 {index}: 发生未知错误. {e}, exc_info=True)continuereturn resultsdef parse_ts(self, ts_str):# 简化版时间解析，实际项目中可复用 parser 中的逻辑try:return datetime.datetime.fromisoformat(ts_str)except:try:return datetime.datetime.fromtimestamp(int(ts_str))except:return Nonedef save_output(self, data, file_path):try:with open(file_path, 'w', encoding='utf-8') as f:json.dump(data, f, indent=2, ensure_ascii=False)logger.info(f数据已保存至: {file_path})except IOError as e:logger.error(f文件写入失败: {e})深度解析：宽容模式 vs 严格模式：在 process 方法中，遇到未知单位，我选择了“使用默认单位”并记录 warning。如果你的业务要求极高，这里应该 raise 异常。这是架构设计的选择，需要根据业务场景定。
exc_info=True 再次出现：在 except Exception 中，我们再次使用了 exc_info=True。当你看到日志里出现 Traceback (most recent call last): 后面跟着一堆文件行号时，不要慌。看最后一行，那是真正报错的地方。往上看，找到你代码里的那一行，问题就在那。运行与测试：如何看懂 StackTrace
代码写完了，怎么跑？怎么测？
1. 准备测试数据
在 data/raw/sample_data.csv 中放入几行脏数据：
2023-10-01 10:00:00, 1.5, m
2023-10-01 10:01:00, 150, cm
invalid_time, 2.0, m
2023-10-01 10:03:00, abc, m
2023-10-01 10:04:00, 3.0, unknown_unit2. 安装依赖
pip install pandas pyyaml3. 运行并观察日志
执行 python main.py。
场景一：时间解析失败
日志输出：
WARNING - 行 2: 时间解析失败, 跳过. 原始值: invalid_time
分析：这是预期行为。parser 或 cleaner 捕获了 ValueError，记录了 warning，跳过了该行。程序没有崩溃。这就是健壮的代码。
场景二：数值转换失败
日志输出：
ERROR - 行 3: 数值转换失败. 原始数据: {'ts': '2023-10-01 10:03:00', 'val': 'abc', 'unit': 'm'}, 错误: could not convert string to float: 'abc'
分析：float('abc') 抛出 ValueError。我们捕获了它，并打印了原始数据。现在你知道哪一行数据坏了，去源头修正数据即可。
场景三：真正的 Bug（模拟）
假设你在 cleaner.py 中写错了一个变量名，比如 self.unit_factors 写成了 self.unit_factor。
日志输出：
ERROR - 行 0: 发生未知错误. 'DataCleaner' object has no attribute 'unit_factor'
Traceback (most recent call last):File main.py, line 28, in modulecleaned_data = cleaner.process(raw_data)File src/cleaner.py, line 32, in processval = val * self.unit_factors[unit]
AttributeError: 'DataCleaner' object has no attribute 'unit_factor'如何解读？看最后一行：AttributeError: ... no attribute 'unit_factor'。告诉你属性名错了。
看堆栈：File src/cleaner.py, line 32。打开 cleaner.py，跳到第 32 行。
修正代码：把 unit_factor 改回 unit_factors。
重新运行。这就是 StackTrace 的正确打开方式。 不要试图读懂每一行库的代码，只看你自己代码所在的那一行和最后的那个错误类型。
优化扩展与工程化建议
当你的雅兰辅助项目跑通后，如何让它更专业？
1. 单元测试
别只用 print 调试。使用 pytest 写单元测试。
# test_cleaner.py
import pytest
from src.cleaner import DataCleaner
import pandas as pd@pytest.fixture
def cleaner():config = {'default_unit': 'm'}return DataCleaner(config)def test_unit_conversion(cleaner):df = pd.DataFrame({'ts': ['2023-01-01'], 'val': ['100'], 'unit': ['cm']})result = cleaner.process(df)assert result[0]['value'] == 1.0 # 100cm = 1m2. 性能优化
如果数据量达到百万级，df.iterrows() 会非常慢。优化方案：使用 pandas 的向量化操作。例如，df['value'] = df['value'].astype(float) * df['unit'].map(unit_factors)。这比循环快几个数量级。
参考：查阅 MDN Web Docs 中的性能相关文档虽然主要面向 JS，但其关于“避免在热路径中执行昂贵操作”的思想是通用的。在 Python 中，避免在循环内做字符串拼接、文件 I/O 等重操作。3. 配置外部化与 Docker 化将 config.yaml 通过环境变量注入，方便在不同环境（开发、测试、生产）切换。
编写 Dockerfile，将依赖打包。这样别人拉取你的代码，docker run 就能跑，解决了“在我电脑上能跑”的千古难题。4. 日志轮转
logs/app.log 会越来越大。使用 logging.handlers.RotatingFileHandler，每天或每 10MB 滚动一次日志，防止磁盘爆满。
小结与互动
今天我们从零搭建了一个雅兰辅助的实战项目原型。解决了：报错看不懂的问题，通过 logging 和 exc_info，你知道了 StackTrace 的读法。
实现了：数据清洗的核心逻辑，包括单位换算、时间解析、异常捕获。
规范了：项目目录结构和工程化流程，包括配置分离、日志记录、单元测试。编程不是为了写出最炫的代码，而是为了写出可维护、可调试、可复用的代码。当 StackTrace 再次出现时，希望你不再是那个被红色字体吓哭的新手，而是那个能精准定位问题的老手。
最后，抛出一个问题给大家讨论：
在实际的水利或 IoT 项目中，你们是如何处理“脏数据”的？是选择直接丢弃并报警，还是进行模糊匹配修正？或者你有更独特的处理策略？
你公司项目里是怎么处理的？欢迎在评论区分享你的踩坑经验和最佳实践。