信用卡欺诈检测实战：从类别不平衡到阈值调优的完整攻略-北京尧图网络

1. 这个经典项目到底在考什么类别不平衡与0.172%的欺诈样本困局1.1 一张31万行的表真正的正样本只有492条Kaggle平台上的信用卡欺诈检测Credit Card Fraud Detection之所以能火这么多年不是因为它的算法有多新而是因为这份数据天然地把“工业级风控的真实困难”压缩到了一个可以单机跑动的表格里。数据集记录的是2013年9月欧洲持卡人的真实交易共284807笔其中欺诈交易只有492笔正样本占比0.172%。换句话说你随便写一行“全部预测为正常交易”准确率就是99.83%。我第一次跑这个项目的时候看到这个数字差点笑出声——这还用建模直接把全部预测成0不就几乎满分了吗直到我真正去提交、去看Private LB分数才意识到这个项目的核心不是“准确率”而是“如何在极端不平衡的数据里把那一小撮欺诈交易抓出来同时不误伤太多正常交易”。这里涉及的第一个基础认知是凭数据分布来判断模型策略而不是凭惯性。这份数据有30个特征列包括Time交易时间距首笔交易的秒数、Amount交易金额、V1到V28PCA降维后的匿名特征最后一列Class是标签0代表正常1代表欺诈。没有缺失值没有明显的ID列干净得像一份教学数据但只要一跑起来就会处处碰壁。1.2 漏过一笔欺诈和误杀一笔正常交易的代价完全不对等大学里的机器学习课通常教的是“最小化错误率”但真实的风控业务根本不是这么算账的。一笔欺诈交易被漏过去银行可能要承担拒付损失金额可能是几千块甚至几万块而一笔正常交易被误判成欺诈客户要经历卡片被冻结、电话核实、重新发卡这一整套流程体验极差严重的还会流失客户。这种“错误代价不对称”决定了信用卡欺诈检测在工业界从来不是单纯的分类问题而是一个带权重的最优化问题。Kaggle上这个经典项目把这种业务矛盾浓缩到了极致如果只看准确率所有模型都会收敛到“把一切判为正常”这个毫无意义的解上但如果你给自己设定一个更合理的优化目标——比如在召回率达到80%的前提下让精确率尽可能高——整个建模思路就会彻底改变。所以在正式动手建模之前必须先想清楚三个问题我要用哪个指标来评估模型不能是accuracy。我要用什么策略来处理类别不平衡不能是硬train一发。模型输出的概率分要怎么转换成业务决策不能直接用0.5当阈值。这三个问题贯穿了整个项目的始终。后面的每一个环节本质上都是在回答其中某一个问题的具体实现。2. 先把手里的牌摸清楚V1-V28、Time、Amount各自藏着什么信息2.1 V1-V28是PCA脱敏后的“马赛克”不要试图还原业务含义很多新手拿到这份数据的第一反应是去搜“V1是什么意思”然后发现搜遍全网也没有标准答案——因为这些特征在发布前就已经做了主成分分析PCA降维和脱敏处理。原始交易数据涉及持卡人的隐私信息银行不可能直接把商户类别、交易地点、设备指纹这些原始字段公开出来只能通过PCA投影成V1-V28这28个匿名特征。PCA特征的一个数学性质是各主成分之间彼此正交不相关这意味着V1到V28两两之间的线性相关性非常弱。我拿到数据后习惯性地画了一张相关性热图结果发现除了个别几个特征之间有小幅相关性外整体上非常干净。这种情况对线性模型非常友好对树模型来说也省去了很多特征去重的麻烦。但要注意PCA做了线性变换它没有改变原始数据的分布形态也没有消除异常值。所以V1-V28里依然存在大量的极端值有些特征的分布甚至在尾部拉了很长的线。我在做特征工程时试过对V1-V28做标准化、分箱、甚至尝试用孤立森林筛异常最后发现树模型对这些特征的处理非常直接而逻辑回归则需要先标准化才能好好收敛。不要试图从业务角度解释V1-V28背后的意义把精力放在数据分布的形态上就好。2.2 Amount看似只有一个数字其实是欺诈行为模式的重要线索Amount交易金额是这份数据里少有的、你能直接用业务常识去理解的原始特征。欺诈交易的金额分布往往和正常交易有明显差异——有的欺诈是“小额试探”每次刷几块钱试卡能不能用有的欺诈是“大额快跑”短时间内把卡内额度刷空。我在画金额分布图时发现正常交易的金额绝大多数集中在很小的区间有一根很长的右拖尾欺诈交易的金额分布相对平缓一些虽然平均金额不算特别高但大额区间的密度明显比正常交易高。因为金额分布是严重右偏的直接用原始数值喂给模型会有问题。线性模型对尺度极其敏感Amount的取值范围从0到25691而V1-V28大多在-5到5之间如果不做处理线性模型的权重会被金额这个特征主导。我的做法是import numpy as np # 方式一对数变换压缩右拖尾 df[Amount_log] np.log1p(df[Amount]) # 方式二RobustScaler基于分位数抗异常值 from sklearn.preprocessing import RobustScaler scaler RobustScaler() df[Amount_scaled] scaler.fit_transform(df[[Amount]])我实测下来对数变换在这个项目里比标准化的效果略好一点因为log1p能把金额的右拖尾压得比较紧而且保持了“小额交易差异敏感、大额交易差异钝化”的特性这和业务的直觉是一致的。至于Time情况要复杂一些值得单独说。2.3 Time特征隐藏的时间顺序处理不当就是泄漏源Time记录的是本笔交易距离数据集中第一笔交易的秒数取值范围从0到172792秒换算过来大约是两天。这个特征很容易被忽略很多人直接丢进模型完事但它在欺诈检测里其实非常微妙。一个重要的观测是欺诈交易在时间轴上存在明显的聚集效应。这不是我一个人的发现很多做这个项目的玩家都注意到欺诈交易并不是均匀地分布在两天里的而是集中在某些时间段爆发。这和现实中的盗刷行为模式一致——不法分子拿到一批卡号后会在某个时间段集中测试、集中盗刷。这意味着Time特征的预测能力可能相当强但同时也带来了泄漏风险如果直接用随机K折交叉验证同一批盗刷团伙的高相似度交易很可能同时出现在训练集和测试集里模型会通过Time这个特征“记住”某些时间段的聚集模式导致本地交叉验证分数虚高。我在项目里做过一组对照实验用随机K-Fold和TimeSeriesSplit分别训练同一套模型结果随机K-Fold下的测试AUC比TimeSeriesSplit高了差不多0.02-0.03。这个差距完全不能忽略。更合理的做法是把Time转换成“小时级别的时间点”特征——比如交易发生在第几小时、星期几等或者干脆在验证方式上用按时间切分的K-Fold来模拟真实场景而不是直接让模型去记忆秒数。2.4 重复样本一份经典数据里的隐藏大坑在数据集清洗环节还有一个很多人不知道的坑这份数据里存在大量完全相同的重复行。我把数据读进来之后用df.duplicated().sum()检查了一下发现有超过一万条重复记录。这是当时比赛期间社区里讨论过的问题原始数据的发布方在处理过程中可能出现了重复导出但对选手来说这些重复样本会直接影响训练和验证。重复样本的影响有两个方面。首先如果不去重训练集和测试集之间就会出现同一条记录同时存在的可能线上分数的可信度会大打折扣其次重复样本会让模型对这部分模式过拟合泛化能力被高估。我的建议是在数据加载后第一时间做一次全字段去重然后再进行后续的特征工程和划分。去重之后样本量会从28万多降到27万多类别比例基本不变但对最终结果的真实性影响非常大。3. 评估指标先于模型换了这把尺子模型方向才不会跑偏3.1 99.83%准确率的陷阱一个“什么都不做”的模型面对这份极度不平衡的数据准确率这个指标已经彻底失效。一个最简陋的baseline——所有样本都预测为0——就能拿到99.83%的准确率任何稍微复杂一点的模型想要超过这个数字都非常困难但这并不意味着那个“全0预测”的模型有任何实用价值。我最初犯的错误就是拿着accuracy当KPI花了大量时间调参结果所有模型的准确率都卡在99.8%到99.9%之间根本分不出好坏。后来我才意识到在这个任务里应该换一把尺子要么用Precision-Recall曲线下的面积AUC-PR要么直接用F1分数或者某个业务目标下的精确率/召回率组合。3.2 为什么Precision-Recall比ROC更诚实ROC曲线和AUC在类别不平衡的情况下会表现得过分乐观理由很简单ROC同时考虑了真正例率TPR和假正例率FPR而FPR的分母是全部负样本的数量。在欺诈检测这种负样本正常交易极其庞大的场景里即使模型产生了大量误报分摊到庞大的负样本基数上FPR依然会非常小所以ROC曲线看起来依然漂亮。而PR曲线的横轴是召回率纵轴是精确率它直接聚焦在“正样本”这个少数类别上任何一次误报都会直接拉低精确率。在这份信用卡数据上我的经验是完全以AUC-PR作为模型选择的依据ROC-AUC只做参考。两者的排名在很多时候是一致的但遇到某些模型时会出现ROC差不多但PR差很多的情况这时候PR曲线给出的信号更可靠。3.3 混淆矩阵的正确读法与其看F1不如看FP和FN的数量F1分数是一个被广泛使用的综合指标但在真实的欺诈检测项目里我建议不要只盯着F1。更好的方式是直接看混淆矩阵里的FP正常交易被误判为欺诈和FN欺诈交易被漏掉的绝对数量。举个例子一份包含27000多笔测试交易的数据里如果模型抓到30笔欺诈中的25笔同时误杀了20笔正常交易这个模型看起来F1还不错。但在真实业务里这20笔误杀意味着20个客户要打电话来投诉运营团队要处理20张冻结卡片的解冻而漏掉的那5笔欺诈可能直接造成几万块的损失。这些数字背后是钱和服务体验不是抽象指标。为了让自己和读者都时刻记得这件事我在项目里写了一个简单的“业务成本计算器”场景数量单次成本假设总成本漏过的欺诈FN5笔2000元/笔10000元误伤的正常交易FP20笔50元/笔1000元成功拦截的欺诈TP25笔避免2000元/笔节省50000元把这个表拉出来之后模型的优化方向就变得非常清晰了在控制FP数量的前提下尽可能降低FN。这个“用业务逻辑指导模型指标”的思路是这个项目能真正帮到工业实践的地方。4. 建模实战三种不平衡处理策略的直接对比4.1 一个不处理不平衡的基线模型用来锚定收益边界在处理类别不平衡之前我建议先跑一个完全不处理的基线模型。我用的是逻辑回归和随机森林各跑了一个baseline不做采样、不设class_weight、不调任何参数直接用默认设置做5折交叉验证。这样做的目的是给自己一个锚点后续所有策略的提升都要以这个基线为参照而不是凭感觉说“某个模型效果不错”。我在实验里得到的结果是默认逻辑回归的F1分数阈值取0.5时只有0.45左右AUC-PR大概在0.70上下随机森林的AUC-PR能到0.75但正样本的召回率依然低得可怜。这个结果符合直觉——不平衡数据下不做任何处理的模型会倾向于把所有样本都预测为多数类少数类的召回率自然上不去。4.2 随机下采样牺牲数据量换取训练集均衡随机下采样的思路非常简单从多数类里随机抽取一部分样本让它和少数类的比例接近1:1或者某个合理比例然后在这个均衡的数据集上训练模型。我最初用的比例是1:1也就是492条欺诈样本对应492条随机抽取的正常样本但这样丢弃了27万多条正常交易里的绝大多数信息模型学到的“正常交易模式”会非常片面。后来我把比例调整为1:3或1:5也就是每条欺诈样本配3到5条正常样本效果明显好于1:1。原因是欺诈样本本身就少如果训练集里两类样本完全均衡模型会把大量精力浪费在一些并不典型的正常交易模式上而保留更多正常样本可以帮助模型学到更准确的“正常分布”。此外下采样还有一个隐性问题训练集的先验概率已经失真了模型输出的概率值会被系统性放大后面必须做概率校准。这一点我在下一章详细展开。4.3 SMOTE合成样本看着美好用起来要谨慎SMOTESynthetic Minority Over-sampling Technique是处理不平衡数据的经典方法它通过对少数类样本在特征空间里做插值来生成新的合成样本。我在这个项目里用imbalanced-learn库跑过一版SMOTE流程是from imblearn.over_sampling import SMOTE from sklearn.model_selection import train_test_split X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.3, random_state42, stratifyy ) smote SMOTE(random_state42) X_resampled, y_resampled smote.fit_resample(X_train, y_train)SMOTE的核心逻辑是在少数类样本的近邻之间连线上生成新样本。如果原始特征的噪声较大或者少数类样本本身就散布在不同的小簇里插值操作很可能会生成一些处于稀疏区域的“伪样本”对模型学习反而是一种干扰。在这份PCA特征数据上SMOTE单独使用的效果比纯随机下采样略好但好得有限更好的做法是SMOTE结合ENNEdited Nearest Neighbors做清洗把生成后落在多数类密集区域的样本剔除掉。我实测SMOTE-ENN的AUC-PR比纯SMOTE大概高了1到2个点。4.4 class_weight和scale_pos_weight被过度低估的性价比之王在处理不平衡的策略里最“便宜”的方法是直接修改损失函数中正负样本的权重。Sklearn里的逻辑回归和随机森林都支持class_weightbalanced参数它会根据类别频率自动调整权重让少数类样本的错误被惩罚得更多。LightGBM和XGBoost里对应的参数分别是is_unbalanceTrue和scale_pos_weight其中scale_pos_weight的推荐初始值通常是负样本数除以正样本数。我在这份数据上的实测体验是class_weightbalanced的行之有效程度被很多人低估了。它不需要丢弃任何数据不需要生成合成样本跑起来也快最终得到的模型效果和下采样、SMOTE非常接近。尤其是逻辑回归配上class_weight之后训练稳定、概率输出自然后面做阈值搜索也顺畅得多。所以我的建议是先跑一个class_weight加逻辑回归的版本作为快速baseline再尝试下采样和SMOTE等更复杂的方案。4.5 模型选型的实测结论逻辑回归被低估树模型先天适配这个项目的模型选择可以总结成一条简单经验逻辑回归是这个任务的“隐藏MVP”而树模型则是综合容错率最高的选择。逻辑回归配合良好的特征缩放在V1-V28这种线性重建特征上表现非常稳定。它不会像深层模型那样需要调一堆超参数也不会像树模型那样容易在少数类样本上过拟合。我跑出来的逻辑回归AUC-PR大概在0.78到0.81之间稍加调参就能到0.83。随机森林的AUC-PR能到0.85左右但在小样本上的过拟合风险更高XGBoost和LightGBM在充分调参后可以到0.87-0.89这是我自己跑出来的最好成绩。如果你不想花太多时间调参我建议用LightGBM加合理的早停early stopping就能稳定拿到不错的分数。如果你想追求极致的性能可以尝试逻辑回归加树模型做stacking第一层用多个模型分别预测概率第二层用逻辑回归把概率拼接起来做最终预测。这种“线性加非线性”的组合在这份数据上是有效的因为PCA特征中有一部分是线性可分模式另一部分则需要树模型去挖掘非线性关系。5. 阈值调整与概率校准从模型分数到业务决策的最后一公里5.1 不要默认0.5PR曲线会告诉你该在哪里切一刀很多新手训练完模型后直接拿predict_proba输出的概率和0.5比较来决定分类。在这份极度不平衡的数据上这个习惯会带来很糟糕的结果。因为我训练好的模型输出的预测概率普遍偏低欺诈样本的预测概率大多集中在0.2到0.7之间取0.5作为阈值会导致大量真实欺诈样本被漏掉。正确的做法是把阈值当作一个可调参数在验证集上根据PR曲线来搜索最优分割点。我写了下面这段简单的阈值扫描代码from sklearn.metrics import precision_recall_curve import pandas as pd precision, recall, thresholds precision_recall_curve(y_val, y_score) # F1最大化 f1_scores 2 * (precision * recall) / (precision recall) best_idx f1_scores.argmax() best_threshold thresholds[best_idx] print(f最佳阈值: {best_threshold:.4f}) print(f对应F1: {f1_scores[best_idx]:.4f})实测下来最优阈值绝不会是0.5。我跑过的几组模型里最优阈值往往落在0.2到0.4之间有些下采样模型甚至需要降到0.1以下。这个发现非常重要模型的排序能力AUC-PR和分类能力F1是两回事前者评估的是“模型能不能把欺诈样本排到前面”后者取决于“你在哪个位置切一刀”。如果你只报告AUC等于只回答了前一个问题但没有回答后一个业务真正关心的问题。5.2 概率校准下采样模型的“起义军”问题如果用了随机下采样训练集里的正负样本比例已经从1:580变成了1:3模型学到的先验概率就已经失真了。这种情况下模型输出的概率是有偏的直接拿出来做阈值搜索或者跟其他模型的分数比较会出问题。我在第一次做下采样实验时就遇到了这个情况模型在验证集上的预测概率普遍很高很多正常交易的概率都跑到0.5以上F1分数很差。解决办法是做一个概率校准probability calibration让模型的输出概率尽量贴近真实概率。Sklearn里提供了Platt Scaling基于逻辑回归的校准和Isotonic Regression基于保序回归的非参数校准两种方法。我在这个项目里用的是CalibratedClassifierCV并且强调一点校准器必须只用验证集来拟合不能把训练集信息泄漏进来。from sklearn.calibration import CalibratedClassifierCV # 假设model已经在下采样后的训练集上训好 calibrated_model CalibratedClassifierCV( model, methodisotonic, # 样本量大时isotonic更灵活 cv5 ) calibrated_model.fit(X_val, y_val)校准之后下采样模型输出的概率分布会明显向真实分布靠拢再去做阈值搜索得到的最优阈值才具有业务参考价值。就我的观察很多Kaggle玩家在下采样方案上分数上不去问题不是出在模型训练而是出在这一步概率校准上。5.3 把业务成本函数直接塞进阈值搜索一个可以复用的思路在工业风控里选择阈值从来不只是为了最大化F1而是为了最小化预期总成本。F1对FP和FN是一视同仁的但业务显然不是。如果你能给出一个粗略的成本估计——比如“一笔欺诈的平均损失是2000元一个被误杀客户的运营加流失成本是50元”——那么你就可以写一个简单的损失函数来搜索阈值def business_loss(threshold, y_true, y_score): preds (y_score threshold).astype(int) fp ((preds 1) (y_true 0)).sum() fn ((preds 0) (y_true 1)).sum() return fp * 50 fn * 2000 thresholds np.arange(0.05, 0.95, 0.01) losses [business_loss(t, y_val, y_score) for t in thresholds] best_t thresholds[np.array(losses).argmin()]这类自定义损失函数在Kaggle比赛的排行榜上通常派不上用场因为比赛的评价指标是固定的。但如果你把目光放远一点就会意识到这个项目真正的价值恰好在这里它逼着你从“模型分数”走到“业务决策”的完整链路。妥善处理这一步你在面试里讲这个项目的时候就能直接跟面试官聊清楚“你的模型能为业务省多少钱”而不是只报一个AUC数字。6. 复盘与踩坑记录这些坑我替你踩过希望你能绕开6.1 标准化必须在划分数据集之后再进行这是入门阶段最常见、最隐蔽、也最容易让人吃亏的问题。很多人在拿到数据后会对全量数据做标准化然后再划分训练集和测试集。这样做表面上没什么问题测试集上的分数也还行但实际上已经发生了数据泄漏——标准化器比如StandardScaler的均值和方差是在全体数据上拟合的它已经“看到”了测试集的分布信息。正确的流程是先划分训练集和测试集然后在训练集上fit标准化器再用这个已经fit好的标准化器去transform测试集X_train, X_test, y_train, y_test train_test_split(...) scaler RobustScaler() X_train_scaled scaler.fit_transform(X_train) X_test_scaled scaler.transform(X_test) # 不重新fit我在这个项目里对比过两种方式的差异正确顺序和错误顺序在AUC-PR上可能只差零点几个点但在某些树模型和线性模型上会被放大到1-2个点。更关键的是这种泄漏会让你的“验证分数”失去对线上分数的预测能力。这一类错误做多了你会下意识怀疑自己的验证流程是否可靠。6.2 强行把Time变成小时特征可能会破坏交易顺序的时序结构Time特征的处理方式会直接影响模型的泛化能力。我一开始参考网上很多教程的做法把Time转换成“交易发生在第几个小时”喂给模型后本地分数好像有提升。但后来仔细一想这里的“小时”是从数据第一笔交易开始计算的相对小时不是一天里的真实钟点它在不同批次的数据里含义完全不同。如果线上业务数据的时间起点不同这个特征就完全失真了。更稳妥的做法有两种一是保留Time的原始数值但把验证方式改成TimeSeriesSplit让模型看到真实的时间顺序二是把Time转成相邻交易的时间间隔比如当前交易与上一笔交易之间的秒数差这个特征在欺诈聚集场景下往往更有区分度。我在多次实验中发现时间间隔特征结合树模型的表现确实不错因为它隐式地捕捉了“欺诈交易经常在短时间内连续出现”这一业务规律。6.3 重复样本不清理交叉验证分数虚高只是时间问题前文提到这份数据有大量重复行。我在清理完之后重跑了整个流程发现AUC-PR比不清洗时低了大概0.5到1个点。这不是模型变差了而是模型不再“作弊”了。如果不清理重复样本相同或高度相似的交易记录可能同时出现在训练集和测试集里模型在测试集上的表现会被严重高估。这种高估到了线上会立刻现出原形。所以每次拿到一份新数据第一步永远是df.duplicated().sum()和df.isnull().sum()确认数据的干净程度再谈建模。特征工程做得再花哨也救不了一个带有泄漏隐患的数据基础。6.4 Kaggle实战中的提交细节从注册到submission.csv的正确姿势再补充一些平台层面的实战经验。Kaggle注册本身如果遇到验证码刷不出来的情况大概率是网络环境问题换个稳定的网络环境一般就能解决。数据集的下载建议直接使用Kaggle API在Kaggle网站上生成API Token后把kaggle.json放到用户目录的.kaggle文件夹下然后执行kaggle competitions download -c credit-card-fraud-detection就能命令行下载数据。如果你用的是Kaggle Notebook可以在右侧的Dataset面板直接一键添加数据集也可以设置环境自动运行、定期输出结果。提交环节有几个容易踩的坑。首先提交文件必须是CSV格式内容通常是id或Time列加预测概率列具体的列名要求要看比赛说明。我在跑这个经典数据集的时候发现提交文件默认用测试集的Time作为索引如果你用了reset_index列名对不上提交时就会报错。其次一定要保证测试集的样本顺序和原始测试集保持一致不要在做特征工程的时候不小心打乱了顺序。本地交叉验证分数和Public Leaderboard分数不一致是这个项目里最常见的困惑。我复盘下来的原因主要有三个一是特征工程或标准化时发生了数据泄漏本地分虚高二是随机K-Fold没有考虑时间顺序模型“偷看”了未来的信息三是提交时概率列名称或索引有误Kaggle后台评分时结果错位。一个个排查过去通常能解决大部分分数不一致的问题。6.5 一点个人体会走完这个项目的完整流程之后我最深的感受是Kaggle竞赛的分数并不等于解决真实业务问题的能力。信用卡欺诈检测这个经典项目之所以适合当作进阶门槛恰恰是因为它逼迫你同时面对“评估指标设计、不平衡处理、概率校准、阈值决策”这四件工业界真正关心的事。如果你只是照着网上的notebook跑一遍、拿个排行榜分数那你得到的只是一个模板如果你独立跑通每一个环节并且能清楚地解释每个选择的理由那么这个项目给你的锻炼远比一个AUC数字值钱得多。

信用卡欺诈检测实战：从类别不平衡到阈值调优的完整攻略

相关推荐

LSTM文本情感分析：门控记忆与词向量如何破解电商评论歧义

Redis生产事故复盘：从大key到缓存穿透的全链路治理

抖音Web端视频采集实战：接口分析与签名参数全解析

更多资讯

智能写作系统如何提升学术论文效率与质量

AT89C51驱动LCD12864显示图片：从取模到刷屏全解析

YOLO道路积水检测数据集构建与模型优化实战

break和continue详解：从嵌套循环到实战避坑指南

BD-RIS非对角反射矩阵的MIMO容量最大化：Matlab仿真与踩坑复盘

英文版Windows安装中文语言包：从获取到DISM实操全指南

今日更新

基于MATLAB的CRI显色指数计算：从SPD光谱到Ra的完整流程

JSP+Servlet+MySQL博客系统源码部署与优化全攻略

蜂窝调度算法 MATLAB 实现：比例公平、轮询与最大 C/I 对比

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？