简介这套基于Python与PHP实现逻辑回归二分法的心脏病预测源码包面向机器学习入门者、Web全栈学习者及需要课程设计参考的高校学生。项目根据年龄、血压、胆固醇等医疗指标借助逻辑回归Sigmoid函数将特征线性组合映射为患病概率模型预测正确率超过84%完整演示了二分类任务从数据到决策的落地过程。压缩包内共8个文件包含heart.csv原始数据集、Python分析脚本、PHP相关配置、项目描述文件等整体大小仅7KB麻雀虽小但结构清晰适合快速阅读理解核心实现。目前已有245人学习浏览。深入研读源码可掌握scikit-learn逻辑回归的建模流程包括数据清洗、缺失值处理、特征缩放、交叉验证及准确率、查准率、查全率、F1分数等评估方法同时可学习PHP如何通过HTTP请求或exec()调用Python模型构建简易用户输入界面并返回预测结果。资源附带README与IDE配置帮助初学者跳过环境搭建障碍直接将精力放在算法原理与系统集成上。1. 84% 正确率背后这套 Python PHP 心脏病预测案例到底在教你什么把压缩包解压后里面并不是什么高深算法而是一条完整的「Python 训练模型 PHP 部署调用」链路heart.csv是数据Analyze.py是训练脚本剩下的 PHP 代码解决的是怎么让人在网页上填指标、拿预测结果。逻辑回归二分法在这个案例里的定位很清楚——用十几个常见体检指标输出一个 0 到 1 之间的患病概率再按阈值判成「有风险 / 没风险」。我拆完这个包最大的感受是它的价值不在模型精度84% 在医疗场景不算惊艳而在于把数据预处理、训练、评估、Web 调用这一整套流程装进了一个适合初学者跟完的骨架里。适合两类人一是刚学完 scikit-learn 但不知道模型怎么落到网页上的 Python 新手二是手里有 PHP 业务、想塞一个机器学习预测功能的 Web 开发者。2. 从 heart.csv 到 84% 正确率逻辑回归训练链路与 Analyze.py 拆解2.1 heart.csv 字段分析与「二分法」本质先看数据。heart.csv是典型的心脏病二分类数据集每一行是一个患者样本最后一列是标签。常见字段如下这套案例里用的就是这类标准指标字段含义取值/类型age年龄连续数值sex性别0 / 1cp胸痛类型0 ~ 3trestbps静息血压连续数值chol血清胆固醇连续数值fbs空腹血糖是否 1200 / 1restecg静息心电图结果0 ~ 2thalach最大心率连续数值exang运动是否诱发心绞痛0 / 1oldpeakST 段压低数值连续数值slopeST 段斜率0 ~ 2ca主要血管数量0 ~ 3thal地中海贫血等级1 / 2 / 3target是否患有心脏病0 / 1「二分法」这个词在这个项目里有两层意思。第一层是指建模目标只判断患病 / 不患病不区分病变严重程度所以输出层只有一个 sigmoid 曲线。第二层是指它的决策逻辑逻辑回归把特征线性组合w·x b送进 sigmoid 函数得到一个 0~1 的概率默认以 0.5 为界大于等于 0.5 判为正类。这样做的好处是解释性强——医生能看到每个字段对概率的贡献方向而不是面对一个黑匣子模型。数据预处理是这个案例里最容易翻车的一段。heart.csv里的ca和thal列经常混入?这样的占位符pandas 读进来会变成 object 类型直接喂给模型会报错。常见做法是先把这两列转成数值把无法转换的变成 NaN再整行丢弃。另外age、chol、trestbps 这类量纲差异大的特征如果不做标准化逻辑回归收敛会变慢而且系数解释起来也不合理。2.2 Analyze.py 训练脚本拆解Analyze.py是整个训练过程的核心逻辑不复杂但每一步都有讲究。下面是把它的常见实现方式整理出来的一段可运行代码import pandas as pd from sklearn.model_selection import train_test_split from sklearn.preprocessing import StandardScaler from sklearn.linear_model import LogisticRegression from sklearn.metrics import accuracy_score, confusion_matrix, classification_report # 1. 读数据 df pd.read_csv(heart.csv) print(原始样本量:, len(df)) # 2. 处理缺失值ca/thal 里可能有 ?先强制转数值再丢弃空行 for col in [ca, thal]: df[col] pd.to_numeric(df[col], errorscoerce) df df.dropna() print(清洗后样本量:, len(df)) # 3. 拆分特征和标签 X df.drop(target, axis1) y df[target] # 4. 标准化连续特征统一到均值为0、方差为1的分布 scaler StandardScaler() X_scaled scaler.fit_transform(X) # 5. 训练/测试集划分stratify 保证正负样本比例在两边一致 X_train, X_test, y_train, y_test train_test_split( X_scaled, y, test_size0.2, random_state42, stratifyy ) # 6. 逻辑回归模型 model LogisticRegression(C1.0, solverlbfgs, max_iter1000, random_state42) model.fit(X_train, y_train) # 7. 评估 y_pred model.predict(X_test) print(Accuracy:, round(accuracy_score(y_test, y_pred), 4)) print(confusion_matrix(y_test, y_pred)) print(classification_report(y_test, y_pred))逻辑说明第 2 步是数据清洗的关键errorscoerce会把无法解析的字符串变成 NaN然后dropna()删掉这些残次样本。不做这一步训练时会直接报could not convert string to float。第 4 步标准化针对的是连续特征逻辑回归本身不强制要求标准化但不标准的输入会让梯度下降路径更曲折收敛更慢。第 5 步的stratifyy很容易被漏掉——如果数据集里正负样本比例本身不均衡简单随机划分可能导致测试集里某一类只剩几个样本评估指标失真。参数说明C1.0是正则化强度的倒数C 越小正则化越强模型越保守solverlbfgs适合中小规模数据集和 L2 正则是当前版本 scikit-learn 的默认选择max_iter1000给足迭代次数防止默认的 100 次在特征未标准化时达不到收敛random_state42固定随机种子保证你每次跑出来的结果可复现。2.3 评估指标为什么 84% 不能只看 Accuracy 一个数README 里记的正确率超过 84%指的就是上面代码accuracy_score输出的数字。但如果你只盯着这个数就忽略了医疗场景里更重要的两个指标查全率Recall和查准率Precision。二分类的预测结果有四种真阳性真正有病判成有病、假阴性有病判成没病、真阴性、假阳性。逻辑回归评估时classification_report会一次性给出所有这些指标。对应关系是指标计算公式关心的场景Accuracy(TP TN) / 总样本整体判断正确比例PrecisionTP / (TP FP)预测有病的人里真有多少有病RecallTP / (TP FN)真有病的人里被捞出来多少F1-score2 × Precision × Recall / (Precision Recall)两者平衡在心脏病预测场景里漏诊假阴性的代价远比误报假阳性高——把一个没病的人多安排一次复查和把一个有病的人放回家性质完全不同。所以训练完模型我一般会先看 Recall 而不是 Accuracy。如果测试集正负样本分布不均Accuracy 甚至会给出一个假安心的数字。这个案例里 84% 的准确率是在默认 0.5 阈值下得到的后面第 5 章会单独说怎么调阈值来改善 Recall。逻辑回归这套评估流程换个数据集就是信用评分、营销响应预测里那套「二分法 混淆矩阵」的底子这也是为什么它常被当作数据挖掘入门案例的原因。3. PHP 调 Python 模型exec、proc_open、cURL 三种姿势怎么选3.1 为什么用 PHP 做外层现有 Web 栈的集成成本最低很多初学者拿到这个包会问Python 直接写 Flask 服务不就好了为什么绕一圈用 PHP答案是这个项目的定位是给已有 PHP 站点塞一个预测功能不是从零造一个独立应用。在 LAMP / LNMP 环境里PHP 已经是现成的请求入口、会话管理和前端渲染层模型预测只是其中一个接口。比起再开一个 Python Web 服务直接在 PHP 里调 Python 脚本部署成本最低也不用处理跨域和双服务联调。当然这个取舍有代价。PHP 和 Python 是两个独立进程每次调用都要经历「启动解释器 → 加载脚本 → 读模型 → 输出结果 → 进程退出」这一整条路径性能比不上常驻内存的 Python 服务。所以下面三种调用方式本质上是在「部署简单」和「性能解耦」之间做选择。3.2 姿势一exec() 直调 临时 JSON 文件传递特征这是最简单的方案也是这个案例里最常见的做法PHP 接收前端提交的指标写成临时 JSON 文件然后exec()执行 Python 脚本Python 读文件、跑预测、把结果输出到 stdoutPHP 再捕获输出做解析。PHP 侧代码?php // 假设前端 POST 过来的数据已经经过基本校验 $input [ age 63, sex 1, cp 3, trestbps 145, chol 233, fbs 1, restecg 0, thalach 150, exang 0, oldpeak 2.3, slope 0, ca 0, thal 1 ]; // 1. 把特征写到临时文件 $inputJson json_encode($input); file_put_contents(/tmp/heart_input.json, $inputJson); // 2. 执行 Python 预测脚本21 把错误信息也收进来 $cmd python3 /var/www/heart_pred/predict.py /tmp/heart_input.json 21; $output []; $returnCode 0; exec($cmd, $output, $returnCode); // 3. 解析 Python 端输出的 JSON $prediction json_decode(implode(\n, $output), true); if (json_last_error() ! JSON_ERROR_NONE) { http_response_code(500); echo 预测服务内部错误请查看日志; exit; } echo json_encode([ probability $prediction[prob], class $prediction[class], message $prediction[class] 1 ? 建议进一步检查 : 风险较低 ], JSON_UNESCAPED_UNICODE);逻辑说明第 1 步把数组编码成 JSON 写入临时文件是为了避免把用户输入直接拼在命令行里——那样既容易出转义问题又有命令注入风险。第 2 步的21很关键不合并 stderr 的话Python 端的报错信息会直接丢到 Web 服务器日志里页面上只看到空输出。第 3 步json_decode(..., true)转成关联数组json_last_error()检查解析是否失败这是 PHP 里最常见的隐蔽坑——不查错误码解析失败时程序毫无反应。参数说明exec()的第三个参数$returnCode是进程退出码0 表示正常退出非 0 表示有异常生产环境应该在拿到退出码之后再做判断。/tmp目录是进程间传文件的临时中转用完即弃不需要持久化。3.3 姿势二Python 起 HTTP 服务PHP 用 cURL 消费如果模型预测会被高频调用每次都拉起一个 Python 进程就太浪费了。常见做法是让 Python 作为常驻 HTTP 服务PHP 用 cURL 去请求。Python 侧可以用 Flask 写一个最小的预测接口import json from flask import Flask, request, jsonify import numpy as np import joblib app Flask(__name__) model joblib.load(heart_model.pkl) scaler joblib.load(heart_scaler.pkl) FEATURE_NAMES [age, sex, cp, trestbps, chol, fbs, restecg, thalach, exang, oldpeak, slope, ca, thal] app.route(/predict, methods[POST]) def predict(): data request.get_json() # 按固定顺序组装特征防止字段错位 features np.array([[data[name] for name in FEATURE_NAMES]]) features_scaled scaler.transform(features) prob model.predict_proba(features_scaled)[0][1] label int(prob 0.5) return jsonify({prob: round(prob, 4), class: label}) if __name__ __main__: app.run(host127.0.0.1, port5000)PHP 侧调用?php $input [age 63, sex 1, cp 3, trestbps 145, chol 233, fbs 1, restecg 0, thalach 150, exang 0, oldpeak 2.3, slope 0, ca 0, thal 1]; $ch curl_init(http://127.0.0.1:5000/predict); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($input)); curl_setopt($ch, CURLOPT_HTTPHEADER, [Content-Type: application/json]); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_TIMEOUT, 30); $resp curl_exec($ch); $httpCode curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if ($httpCode ! 200) { http_response_code(502); echo 预测服务不可用; exit; } $result json_decode($resp, true); echo 患病概率: . $result[prob] . , 判定: . $result[class];逻辑说明Python 侧把模型用joblib持久化成.pkl文件服务启动时加载一次之后每个请求直接复用彻底避开重复加载模型的时间开销。FEATURE_NAMES列表是整个链路的核心约束——PHP 传数组时按键名取值Python 按列表顺序组装谁先谁后都不会错位。参数说明CURLOPT_TIMEOUT设为 30 秒是必须的。Flask 开发服务器是单进程如果并发请求排队某个请求超过 30 秒时 PHP 能主动断开而不是无限等下去。127.0.0.1表明服务只监听本机不对外开放Nginx 那边也不会暴露 5000 端口。3.4 三种调用方式怎么选一张表格说清边界调用方式进程模型部署复杂度并发能力适合场景exec() / shell_exec每次请求拉一个新 Python 进程最低无需额外服务差高并发会堆积低流量内部工具、学习项目proc_open()可控子进程可并行读写中代码量多中可管理超时需要捕获 stdout / stderr 的场景cURL Python HTTP 服务Python 进程常驻中需要管理两个服务好配合 Gunicorn 可扩展生产环境、预测频率高的场景这个案例源码包默认给的是 exec 路线因为它简单直接适合跟着学。但如果你要部署到线上我的建议很明确直接走 cURL Flask 那套哪怕只是单机部署。原因只有一个——不需要为每一次预测支付 Python 解释器启动的代价也不需要担心 exec 卡死把 PHP-FPM 进程拖垮。后者的坑下一章专门说。4. 部署避坑PHP 环境下逻辑回归预测常见的五个翻车现场4.1 进程与命令执行类坑坑一exec() 执行后页面一直转圈进程不退出。现象浏览器请求预测接口后 30 秒以上无响应PHP-FPM 日志里没有任何报错重启 PHP 进程才恢复。如果有人在网上搜「exec 执行完成后如何中断 php」多半就是卡在这。原因exec()是阻塞调用PHP 会一直等着子进程结束。Python 端如果print了大量日志stdout 管道缓冲区被写满子进程就会阻塞在写操作上父进程又等着子进程退出双方死锁。训练日志打得多的时候这个问题几乎必现。解决把日志从 stdout 挪走。在生产里Python 端只向 stdout 输出一行最终 JSON训练过程日志全部写到文件比如sys.stderr重定向到日志文件。另外一定要加超时兜底用proc_open()替代exec()配合proc_terminate()强杀超时子进程?php $cmd python3 /var/www/heart_pred/predict.py /tmp/heart_input.json; $descriptors [ 0 [pipe, r], 1 [pipe, w], 2 [pipe, w] ]; $proc proc_open($cmd, $descriptors, $pipes); if (!is_resource($proc)) { http_response_code(500); exit; } stream_set_blocking($pipes[1], false); $output stream_get_contents($pipes[1]); $errOutput stream_get_contents($pipes[2]); $status proc_get_status($proc); if ($status[running]) { proc_terminate($proc); // 超时强制结束避免拖垮 PHP-FPM } proc_close($proc); echo $output ?: 进程异常错误: . $errOutput;逻辑说明proc_open()之所以比exec()可控是因为它给了你独立的 stdin / stdout / stderr 管道可以非阻塞读取也可以随时查进程状态。stream_set_blocking(false)让读操作不等待配合proc_terminate()就能实现「超时即杀」。血泪经验没有超时管理的 exec 调用线上环境迟早会被一次 Python 异常拖成 502。坑二exec 返回 127 或命令找不到网页显示 No such file。现象本地命令行跑得好好的放到网页上就报 127或者提示python3: command not found。原因PHP-FPM 运行时的环境变量 PATH 和你在终端里看到的不一样通常更精简没有/usr/local/bin这类路径。尤其是用编译安装的 Python 或虚拟环境时python3命令在 web 环境里根本找不到。解决命令里写绝对路径不要依赖 PATH。先which python3查清楚解释器路径然后// 写死绝对路径或者用虚拟环境里的 python $cmd /usr/local/bin/python3 /var/www/heart_pred/predict.py /tmp/heart_input.json;Python 脚本内部也建议用sys.executable打印一下当前解释器路径确认 web 环境加载的是不是同一个 Python。这个检查 30 秒就能做完能省掉后面一整天的排查时间。4.2 数据、编码与权限类坑坑三预测结果全是 0查全率事故。现象接口 200 正常返回概率值也能算出来但所有输入都判成 class 0怎么调阈值都没用。原因PHP 传给 Python 的字段顺序和训练时X的列顺序不一致。如果 PHP 直接按数组序转 JSON而 Python 那边按dict.values()取值顺序对不上模型就白训练了。这种情况下模型实际是把「血压」当成「年龄」在算系数全错位。解决在 Python 预测脚本里定义FEATURE_NAMES列表按名字明文取值import json, sys, numpy as np FEATURE_NAMES [age, sex, cp, trestbps, chol, fbs, restecg, thalach, exang, oldpeak, slope, ca, thal] input_data json.load(open(sys.argv[1], encodingutf-8)) features np.array([[input_data[name] for name in FEATURE_NAMES]])逻辑说明用白名单字段强约束顺序比让 PHP 端「保证数组顺序」可靠得多。因为 PHP 关联数组的遍历顺序和写入顺序通常一致但一旦中间有人做了一次array_values()或者从数据库里取值顺序就乱了。字段名对齐之后这个坑基本就消失了。坑四json_decode 返回 null页面一片空白。现象PHP 端拿到 exec 的输出后解析出来的结果是 nullvar_dump也是 null页面没有任何输出。原因Python 端print了不止一个 JSON——比如模型加载时打了一行 sklearn 警告或者输出中混入了非 ASCII 字符被终端编码折腾成了乱码。json_decode遇到前置字符就会返回 null而且不报错。解决在 PHP 端先检查json_last_error()同时把输出的完整内容记录下来再解析。更稳妥的做法是Python 端把结果直接写入文件PHP 读文件解析完全绕开 stdout 编码问题。再有就是 Python 端print(json.dumps(result, ensure_asciiTrue))保证输出是纯 ASCII不会触发任何编码转换。坑五Python 写临时文件失败PHP-FPM 日志报 Permission denied。现象第一次部署时接口 500查看predict.py报错信息是[Errno 13] Permission denied: /tmp/heart_input.json或者写入 web 目录失败。原因PHP-FPM 的运行用户通常是www-data或nobody它对某些目录没有写权限。尤其当网页和预测脚本放在/var/www/html下时该目录默认权限是 755只有 root 有写权限。在强化配置的系统里/tmp 也可能被挂成noexec或受保护状态。解决单独建一个运行时目录比如/var/www/heart_pred/runtime授予 PHP-FPM 用户写权限mkdir -p /var/www/heart_pred/runtime chown www-data:www-data /var/www/heart_pred/runtime然后 PHP 和 Python 两端的临时文件全部指向这个目录。不要图省事用chmod 777那意味着任何本地用户都能写等于给服务器开了个后门。正确姿势是属主设给www-data组内其他用户只读就够了。5. 调参与评估损失函数、C 值网格扫描与 0.5 阈值以外的选择5.1 逻辑回归损失函数和两种调参路径逻辑回归虽然名字带「回归」但它优化的是对数损失Log Loss也叫交叉熵损失。对单个样本来说预测概率是p真实标签是y损失是loss -(y × log(p) (1 - y) × log(1 - p))当真实标签是 1 时模型预测概率越接近 0损失越大预测越接近 1损失趋近于 0。整个训练过程就是让所有样本的损失之和最小化。如果你在实训平台上刷过逻辑回归损失函数的题会发现绝大多数题目卡的就是这个式子——它直接决定了梯度的方向也决定了为什么逻辑回归用 sigmoid 而不是线性回归的平方误差。理解损失函数之后调参就有了方向。这个案例里最重要的超参数是C正则化强度的倒数。C 越小正则化越强模型越倾向于把权重压缩到接近 0抑制过拟合C 越大正则化越弱模型在训练集上拟合得更用力但可能泛化变差。常见做法是用对数网格搜索不要傻傻地线性扫from sklearn.model_selection import GridSearchCV from sklearn.linear_model import LogisticRegression param_grid { C: [0.001, 0.01, 0.1, 1, 10, 100], solver: [lbfgs, liblinear] } model LogisticRegression(max_iter1000, random_state42) grid GridSearchCV(model, param_grid, cv5, scoringroc_auc) grid.fit(X_scaled, y) print(最佳参数:, grid.best_params_) print(最佳得分:, grid.best_score_)参数说明scoringroc_auc比accuracy更能反映排序能力尤其在二分类概率输出场景下cv5表示 5 折交叉验证每一折的训练集里都有足够样本让模型学规律。lbfgs和liblinear的差别在于后者更适合小数据集和 L1 正则前者收敛更快、内存占用更低。对heart.csv这个体量几百行来说两者差距很小但liblinear在二分类上更稳。第二种调参路径是「二分法逼近」先在 [0.001, 100] 这种大范围里取对数等分点跑一轮找到最优区间再在最优区间里用二分法原则缩小区间继续测。本质上这是把数值优化里的二分查找思想用在超参数搜索上比 GridSearch 的无脑全扫省一半时间。对小数据集来说全扫也就几秒但我养成这个习惯后换到大数据集时省下的时间非常可观。5.2 交叉验证让 84% 这个数字不再「玄学」只跑一次训练测试划分就拿到的 84%严格来说是个随机结果。换一个random_state数字可能在 80%~86% 之间波动。要判断模型到底靠不靠谱标准做法是交叉验证——把数据切多份轮流拿一份当测试集其余当训练集最终看多个测试折的平均分和标准差。from sklearn.model_selection import StratifiedKFold, cross_val_score from sklearn.linear_model import LogisticRegression model LogisticRegression(C1.0, solverlbfgs, max_iter1000) skf StratifiedKFold(n_splits5, shuffleTrue, random_state42) scores cross_val_score(model, X_scaled, y, cvskf, scoringaccuracy) print(5折准确率:, scores) print(均值: {:.4f} 标准差: {:.4f}.format(scores.mean(), scores.std()))逻辑说明StratifiedKFold是分层采样每一折里正负样本比例都尽量接近全局比例避免某一折纯属运气。shuffleTrue让样本顺序不再影响划分结果。标准差如果超过 0.02说明模型对数据划分敏感这时候要优先怀疑特征稳定性而不是继续堆数据。交叉验证的分数才是写进 README 时应该用的数字——它把「一次 84%」变成了「平均 83.5%波动 ±1.8%」后者才是可复现的结论。5.3 阈值调整把概率翻译成风险等级逻辑回归默认用 0.5 当判定边界这是很多人从来没动过的出厂设置。但在医疗场景里这个阈值未必合理。想想看漏诊一个真实病人假阴性的代价比误报一个健康人假阳性更高。如果你想让模型更「敏感」把更多疑似病例捞出来正确做法是降低阈值——比如从 0.5 降到 0.4甚至 0.3。阈值的选取可以用一个简单的循环来完成不需要任何高级算法import numpy as np probabilities model.predict_proba(X_test)[:, 1] for threshold in np.arange(0.2, 0.8, 0.05): preds (probabilities threshold).astype(int) tn, fp, fn, tp confusion_matrix(y_test, preds).ravel() recall tp / (tp fn) if (tp fn) 0 else 0 precision tp / (tp fp) if (tp fp) 0 else 0 print(f阈值 {threshold:.2f} | Recall {recall:.3f} | Precision {precision:.3f}) # 输出示例: # 阈值 0.45 | Recall 0.923 | Precision 0.800 # 阈值 0.50 | Recall 0.846 | Precision 0.846 # 阈值 0.55 | Recall 0.846 | Precision 0.875逻辑说明predict_proba返回的是概率列取[:, 1]表示取正类概率。改变阈值只影响最终判定边界不影响模型本身所以可以放心地在验证集上反复试验。从上面对比能看出把阈值从 0.5 降到 0.45Recall 从 84.6% 升到 92.3%换来的代价是 Precision 从 84.6% 掉到 80%。这个交换在医疗筛查场景里通常是划算的——宁可多做一次复查也不能放走一个病人。把选好的阈值回写到预测脚本里就是最终的生产逻辑。顺便说一句这种「概率输出 阈值判定」的结构换成信用评分场景也完全一样——模型输出违约概率银行再定一个「是否进入人工审批」的分数线。这也是为什么逻辑回归哪怕再不花哨依然是信贷、医疗这类强解释性场景的首选。6. 进阶技巧把预测接口封装成带概率和分级建议的稳定服务6.1 接口协议设计Python 只输出 JSONPHP 只做透传最后一个建议把整个预测链路的结果格式固定下来。不要接口里输出一堆裸数字前端再猜含义要让 Python 端一次性给出概率、类别和给用户看的建议文案。这样 PHP 端只是透传前端展示逻辑完全解耦。# predict.py 最终输出格式 result { prob: round(prob, 4), class: label, level: 高风险 if prob 0.6 else (中风险 if prob 0.4 else 低风险), advice: 建议尽快做进一步检查 if prob 0.6 else 建议保持观察定期复查 } print(json.dumps(result, ensure_asciiTrue))部署完成后我习惯做一次「回灌验证」从heart.csv里挑一行已知target1的样本手动把字段填进页面提交看返回结果是不是 class 1再挑一行target0的样本确认 class 0。这一步能同时验证 PHP 传参、Python 读取、模型加载、结果输出整条链路是否真实连通——不是接口返回 200 就算完成而是结果对得上已知标签才算。从那以后我每次部署这类 Python 模型加 PHP 壳的项目都会强制走一遍这套验证流程先处理特征顺序再检查编码然后回灌测试数据最后才敢把接口交给前端联调。这个习惯是我被「接口 200 但数据全乱」这种情况坑过两次之后养成的。希望这篇拆解能帮你绕过这些我走过的弯路顺利把这套源码跑起来。本文还有配套的精品资源点击获取
