2. MATLAB工程数据环境搭建

在MATLAB中做工程数据分析，真正影响效率的往往不是算法本身，而是数据环境是否清晰。一个可复现的工程通常要回答四个问题：变量现在在哪里、代码如何找到数据文件、处理逻辑如何被复用、文件改动如何被追溯。本节围绕工作空间、路径管理、脚本与函数、工程数据文件组织与版本控制基础展开，目标是搭建一个能长期维护的MATLAB工程数据环境。

一、工作空间：变量的生命周期与内存边界

工作空间（Workspace）是MATLAB当前会话中所有变量的集合，它存在于内存中，随会话结束而消失。理解工作空间的关键是区分“变量作用域”和“持久化”。在命令行或脚本中创建的变量属于基础工作区（base workspace），而函数内部创建的变量属于函数工作区，函数执行结束后默认被清除。这意味着函数不能依赖基础工作区中“碰巧存在”的变量，否则代码不可复现。

常用管理命令包括：who 列出变量名，whos 列出变量名、大小、字节数和类型，clear 删除变量，clearvars -except 保留指定变量，save 与 load 用于持久化。例如，一个传感器数据分析工程中，原始数据可能占用数百MB，若在调试时反复加载，会显著拖慢速度。此时可先保存为 .mat 文件：

raw = readmatrix('sensor_raw.csv');      % 读取原始CSV
meta = struct('fs', 1000, 'unit', 'mV'); % 采样率与单位
save('sensor_session.mat', 'raw', 'meta', '-v7.3');
clearvars raw;                            % 释放内存，保留meta
whos                                      % 查看当前内存占用

这里 -v7.3 支持大于2GB的变量。判断是否该清理内存，可以观察 whos 输出的Bytes列，若单个变量超过可用内存的30%，就应考虑分块处理或保存到磁盘。工作空间不是仓库，而是运算现场，长期数据应落到工程数据文件中。

二、路径管理：让代码稳定找到文件

MATLAB搜索文件的顺序由搜索路径决定。当调用 load('data.mat') 时，MATLAB会依次在当前文件夹和搜索路径中查找。路径管理的核心原则是：不要依赖“当前文件夹恰好正确”，而要让工程自带路径配置。

常用函数有 pwd（当前文件夹）、addpath、rmpath、genpath、path。一个稳健的做法是在工程根目录放置 setup_project.m，用相对路径把子文件夹加入搜索路径：

root = fileparts(mfilename('fullpath'));   % 当前脚本所在目录
addpath(genpath(fullfile(root, 'src')));   % 加入所有源码子目录
addpath(fullfile(root, 'config'));         % 加入配置目录
dataDir = fullfile(root, 'data', 'raw');   % 数据目录用变量传递
fprintf('工程根目录: %s\n', root);

这样无论从哪个文件夹启动MATLAB，只要运行一次 setup_project，路径就一致。需要避免的是把绝对路径写死在脚本里，例如 D:\某同学\项目\data，一旦换机器就会失败。路径配置应作为工程的一部分被版本控制。

三、脚本与函数：从一次性操作到可复用模块

脚本（script）是没有输入输出参数的 .m 文件，适合记录一次完整分析流程；函数（function）有明确输入输出，适合封装可复用逻辑。工程中常见的误区是把所有代码写进一个长脚本，导致变量互相污染、无法单独测试。合理的划分是：脚本负责“编排”，函数负责“计算”。

例如，把异常值检测封装为函数：

function [clean, idx] = removeOutliers(x, method, k)
% removeOutliers 按指定方法剔除异常值
% x: 输入向量; method: 'zscore' 或 'iqr'; k: 阈值倍数
switch method
    case 'zscore'
        z = abs((x - mean(x, 'omitnan')) ./ std(x, 'omitnan'));
        idx = z > k;
    case 'iqr'
        q = quantile(x, [0.25 0.75]);
        iqrVal = q(2) - q(1);
        idx = x < q(1) - k*iqrVal | x > q(2) + k*iqrVal;
    otherwise
        error('未知方法: %s', method);
end
clean = x(~idx);
end

调用时 [clean, idx] = removeOutliers(raw, 'iqr', 1.5)，输入、输出、阈值都显式可见。判断函数是否合格，可以检查三点：是否有明确的输入输出、是否不依赖外部变量、是否对非法输入给出错误提示。满足这三点，函数才能被其他脚本安全复用。

四、工程数据文件组织与版本控制基础

工程目录应让数据、代码、配置、结果各归其位。一个可参考的组织结构如下：

project_root/
├─ setup_project.m        % 路径初始化
├─ config/                % 参数配置
│   └─ params.json
├─ data/
│   ├─ raw/               % 原始数据，只读
│   ├─ interim/           % 中间结果
│   └─ processed/         % 清洗后数据
├─ src/                   % 函数与类
├─ scripts/               % 分析脚本
├─ results/               % 图表与报告
└─ README.md

原始数据放入 data/raw 后不再修改，所有清洗结果写入 data/interim 或 data/processed，这样任何结果都能追溯到原始输入。版本控制方面，Git适合管理代码、配置和小型文本数据，但不应直接提交大型二进制数据。可在工程根目录添加 .gitignore：

data/raw/*.csv
data/interim/
results/
*.mat
*.asv

对于必须版本化的大数据，可使用 Git LFS 或外部数据存储，并在 README 中记录数据来源、采集时间、字段含义和校验值（如文件大小或哈希）。每次提交应写清“改了什么、为什么改”，例如“修正removeOutliers的IQR边界条件”。这样，当三个月后结果出现差异时，可以通过 git log 和 git diff 定位到具体改动。

把上述四部分连起来看：工作空间负责运算时的变量，路径管理保证代码能找到文件，脚本与函数划分职责，目录结构与版本控制保证工程可追溯。实际搭建时，建议先建立目录骨架，再写 setup_project.m，然后把第一个数据处理逻辑封装成函数，最后初始化Git并提交一次。这样得到的不是一堆散落的 .m 文件，而是一个可以持续迭代的工程数据环境。