可直接运行的数据库系统概论课程设计包：MySQL导入建表与事务实验避坑-北京尧图网络

简介山东科技大学数据库系统概论课程设计是一份面向高校数据库课程学习者与初学者的实践资料围绕数据表的创建与修改展开帮助读者把SQL建表、改表等课堂概念落到可运行的程序中。压缩包共5个文件以2个txt说明与测试数据、1个cpp源代码、1个o编译中间文件及1个exe可执行文件组成整体约197KB体积轻便下载后可直接对照使用。已有682人学习具备一定参考热度。资源价值在于将CREATE TABLE、ALTER TABLE等操作逻辑写入源码并编译为可执行程序配合预设测试数据验证字段增删改、属性调整与字段顺序变化等场景便于观察SQL命令的实际效果说明文档则对设计目标、操作步骤与注意事项作出指引适合课程设计复现、实验调试和数据库基础操作练习。1. 一套能直接跑的数据库系统概论课程设计包真正省掉的是什么数据库系统概论课程设计最耗时间的环节从来不是写那几十行 SQL而是把环境、表结构、初始化数据和演示流程对齐——很多人卡在第三天ER 图上的“选课”多对多联系还画不利索更别说后面的事务实验和报告。这套资源的思路是反过来的先给你一份导入就能跑的库结构和范例数据让你看到数据长什么样再回头解释为什么这么拆表、为什么这个字段要单独拎出来做联系表。它适合两类人正在赶课程设计、需要一周内交出可演示系统的学生以及想快速复习一遍建表、视图、触发器、存储过程、隔离级别这些内容的从业者把它当成一个最小可跑的沙盒。要提前说清楚的是包里给的是骨架和范例数据业务规则、报告结论得自己补原样交上去大概率会被追问细节。2. 从压缩包到可连接实例版本、字符集与导入顺序先把最容易返工的两件事定死数据库大版本和字符集。这两项一旦在导入完成后再改代价不是改一个配置而是重新灌一遍数据、重跑一遍对象脚本中间还得处理外键顺序。2.1 先扫脚本判断版本而不是先装数据库课程设计类的 SQL 脚本往往是从不同年份的资料里拼出来的有的片段是旧版本语法有的用了新版本特性。装完数据库再执行报错信息通常很绕——比如一条授权语句在 8.0 上报 1064 语法错误新手很容易以为是少了分号。正确做法是解压后先做一次静态扫描。# 在解压目录下执行判断这套脚本面向哪个大版本 # -r 递归子目录-n 显示行号-i 忽略大小写-E 扩展正则 grep -rniE row_number|over *\(|with recursive ./sql/ \ echo 含窗口函数或 CTE需要 8.0 及以上 \ || echo 无窗口函数5.7 也能跑 grep -rniE grant .* identified by ./sql/ \ echo 存在旧版授权语法8.0 需拆成 CREATE USER GRANT grep -rniE utf8mb4_0900|collation * ./sql/ | head -20这段扫描解决三类问题。第一类是窗口函数和公用表表达式8.0 才支持5.7 直接报 1064第二类是GRANT ... IDENTIFIED BY这种把建用户和授权写在一起的旧语法8.0 已经拆开必须改成CREATE USER加GRANT两步第三类是排序规则utf8mb4_0900_ai_ci是 8.0 默认5.7 不认识导入时会报 1273 未知排序规则。三条扫完装哪个版本就不用猜了。字符集同理别等中文变成问号再回头查。库里、表里、连接层三处必须一致脚本头部通常会有SET NAMES utf8mb4但命令行导入时如果客户端默认字符集不是它这条语句也救不回来。我一般会在导入命令里显式带上--default-character-setutf8mb4把连接层钉死。提示如果机器上已经装了 5.7而脚本又确实用了窗口函数别硬改脚本降级语法直接换 8.0 更省事。降级改写容易在OVER(PARTITION BY ...)这类地方埋下结果不一致的隐患。2.2 四段式导入顺序错一步就报 1146资源包里的 SQL 通常不是一个文件而是一组按前缀编号的脚本。常见的拆分逻辑是删库建库、建表与约束、灌初始数据、建视图触发器存储过程最后是用户与权限。这个顺序不是随便排的视图依赖表触发器依赖表外键依赖被引用表任何一步提前都会撞上ERROR 1146 Table doesnt exist。#!/usr/bin/env bash # 批量导入脚本任一环节失败立即中断避免留下半截状态 set -euo pipefail DBcourse_design CLImysql -uroot -p --default-character-setutf8mb4 # 第一步重建库统一字符集与排序规则 $CLI -e DROP DATABASE IF EXISTS ${DB}; CREATE DATABASE ${DB} DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 第二步按文件名排序依次执行 01 到 04 for f in sql/0*.sql; do echo 正在执行 ${f} $CLI ${DB} ${f} done echo 导入完成set -euo pipefail是这段脚本的核心-e让任何一条命令返回非零就退出-u让未定义变量直接报错-o pipefail让管道中任一环节失败都能被捕获。没有这三个选项某个脚本中途报错但退出码是 0后面的脚本继续跑最后得到一个“表建了一半、数据灌了一半”的库排查成本翻倍。--default-character-setutf8mb4放在客户端命令上而不是脚本里是因为它作用于连接建立阶段比脚本内的SET NAMES更早生效。如果包里带了00_drop.sql这类文件注意它可能包含DROP DATABASE第一次导入前确认里面写的库名和你准备用的库名一致别把已有库误删。2.3 导入完成后先跑三条自检别急着打开客户端看导入脚本没有报错不等于导入成功。表可能建了但数据没进去字符集可能库对了表不对时区可能差八小时。三条查询能把大部分问题挡在前面。-- 1. 基础表数量是否符合预期对照资源包里的建表脚本数 SELECT COUNT(*) AS base_table_cnt FROM information_schema.tables WHERE table_schema course_design AND table_type BASE TABLE; -- 2. 每张表的行数找出该有数据却为空的表 -- 注意 table_rows 是 InnoDB 的估算值精确值仍需 COUNT(*) SELECT table_name, table_rows, engine, table_collation FROM information_schema.tables WHERE table_schema course_design ORDER BY table_name; -- 3. 库级字符集、排序规则与当前会话时区 SELECT character_set_database AS db_charset, collation_database AS db_collation, time_zone AS session_tz, system_time_zone AS system_tz;第一条查询的结果应该和01_schema.sql里CREATE TABLE的条数对得上少一张就说明某个建表语句被静默跳过了——常见原因是脚本里用了CREATE TABLE IF NOT EXISTS前一次失败留下的残表让这次直接跳过。第二条重点看table_rows为 0 的表InnoDB 的估算值虽然不准但 0 通常意味着真的没数据或者统计信息还没更新可以补一条ANALYZE TABLE再看。第三条里time_zone如果是SYSTEM而系统时区不是东八区后面所有TIMESTAMP字段的显示值都会偏移这个坑留到第 5 章细说。三条都过了再考虑用图形化客户端连上去点点看。反过来先开客户端很容易被界面上的“表已存在”提示误导以为导入成功了。3. 从 ER 图到建表语句概念设计怎么落成物理结构课程设计里最容易失分的环节是 ER 图和建表脚本对不上——图上画了五个实体三个联系脚本里只有四张表答辩时被问一句“这个联系去哪了”就很难圆。这一章把转换规则、范式取舍和字段类型三件事拆开说。3.1 联系类型的转换规则与主键选择ER 图里的联系转成表规则是固定的但每一条都有边界。联系类型转换方式课程设计里的典型例子1:1合并到任意一端外键上加唯一约束学生与学籍档案1:N外键放在 N 端不加唯一约束教师与所授课程M:N单独建联系表两端主键做联合主键学生与课程的选课多值属性单独建表外键指回主体学生的联系电话弱实体单独建表主键包含所属实体的主键订单明细依赖订单选课表是这套资源里最值得琢磨的一张。用(student_id, course_id)做联合主键天然能防重复选课插入同一组合直接报主键冲突但成绩字段需要频繁更新联合主键的更新代价偏高而且后续如果要加“重修”场景同一学生同一课程多条记录联合主键就撑不住了。我一般的做法是加一个自增代理键做主键把(student_id, course_id, term)做成联合唯一索引既保留防重能力又给业务留了口子。代理键和业务主键之争在课程设计里没有标准答案但有判断依据如果这个实体的业务标识会变学号可能升位、课程编号可能调整用代理键如果永远不变且长度固定业务主键更直观调试时看 ID 就知道是谁。3.2 三范式的判定与反范式的安全边界判断一张表是否满足第三范式方法是从主键出发画函数依赖主键决定所有非主属性且非主属性之间不能互相决定。选课表里如果塞了course_namecourse_id决定course_name而course_id又不是选课表的主键这就是传递依赖违反 3NF。但实际做课程设计时全部严格范式化会带来另一个问题报表查询要 join 四五张表写起来长、跑起来慢。这时候需要判断哪些冗余是安全的。安全冗余只有两种场景第一种是不可变快照。比如成绩单上要记录课程名称和学分这两项在选课当时就固定了后续课程改名不应该影响历史成绩单。这种冗余是有业务含义的不是偷懒。第二种是可重建的汇总字段。比如班级表里存student_count真实来源是学生表按class_id分组计数。这种字段只要保证有触发器或定时任务维护就不会出现数据不一致。风险在于维护逻辑漏了某条更新路径所以必须配套一个校验查询。-- 汇总字段一致性校验找出人数对不上的班级 SELECT c.class_id, c.student_count AS cached_cnt, COUNT(s.student_id) AS real_cnt FROM class c LEFT JOIN student s ON s.class_id c.class_id GROUP BY c.class_id, c.student_count HAVING cached_cnt real_cnt;这条校验应该写进实验报告的“数据完整性验证”一节答辩时能直接说明冗余字段是怎么保证一致性的。除此之外的冗余比如把教师姓名冗余到选课表都属于给自己挖坑——教师改名时要更新多少行谁都说不清。3.3 建表脚本里的类型、约束与默认值字段类型选错是课程设计里最隐蔽的扣分点因为数据量小的时候看不出问题数据一多或者一算总分就露馅。CREATE TABLE student ( student_id CHAR(10) NOT NULL COMMENT 学号定长业务主键, name VARCHAR(30) NOT NULL COMMENT 姓名留足多字节空间, gender CHAR(1) NOT NULL DEFAULT M COMMENT M/F不用 ENUM 避免扩值要 ALTER, birth_date DATE NULL COMMENT 出生日期只存日期不存时间, class_id INT NOT NULL COMMENT 所属班级, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 入库时间, PRIMARY KEY (student_id), KEY idx_class (class_id), CONSTRAINT fk_student_class FOREIGN KEY (class_id) REFERENCES class (class_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT学生表; CREATE TABLE score ( score_id BIGINT NOT NULL AUTO_INCREMENT, student_id CHAR(10) NOT NULL, course_id CHAR(8) NOT NULL, term CHAR(11) NOT NULL COMMENT 学期如 2024-2025-1, score DECIMAL(4,1) NULL COMMENT 百分制保留一位小数, PRIMARY KEY (score_id), UNIQUE KEY uk_stu_course_term (student_id, course_id, term), KEY idx_course_score (course_id, score), CONSTRAINT fk_score_student FOREIGN KEY (student_id) REFERENCES student (student_id), CONSTRAINT fk_score_course FOREIGN KEY (course_id) REFERENCES course (course_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT选课与成绩表;几个参数值得单独说。student_id用CHAR(10)而不是VARCHAR定长字段在索引里不存长度前缀等值查询略快但更重要的是长度约束本身就是一种校验超长学号插不进去。成绩用DECIMAL(4,1)而不是FLOAT浮点数在做AVG和求和时会出现59.999999这种值报告里一打印就尴尬。gender用CHAR(1)加应用层校验不用ENUM因为 MySQL 的ENUM增加取值要执行ALTER TABLE重建表结构数据量大了很慢。外键约束要显式命名。不命名的外键在删除时会生成student_ibfk_1这种随机名字后面要DROP FOREIGN KEY时还得先去information_schema里查名字。命名规范建议fk_子表_父表索引建议idx_字段联合索引按最左列命名。还有一个容易忽略的点CHECK约束在 8.0.16 之前只解析不执行。也就是说你在 5.7 上写CHECK (score BETWEEN 0 AND 100)插入 150 分照样成功。如果资源包面向 5.7成绩范围校验必须放在触发器或应用层不能指望CHECK。4. 视图、索引、触发器、存储过程四个加分项怎么落地课程设计的评分点通常集中在“是否使用了数据库高级对象”。这四个对象的共同特点是写出来容易写对不容易而错误往往在演示时才暴露。4.1 视图与索引把高频查询路径固定下来视图的价值在于把多表 join 的复杂度封装起来让上层查询只面对一张“宽表”。课程设计里最典型的视图是学生成绩视图把学生、课程、成绩三张表连起来再拼上课程学分算加权。CREATE OR REPLACE VIEW vw_student_score AS SELECT s.student_id, s.name AS student_name, c.course_id, c.course_name, c.credit, sc.term, sc.score, -- 绩点换算60 分以下记 0避免负数 CASE WHEN sc.score 60 THEN ROUND((sc.score - 50) / 10, 1) ELSE 0 END AS grade_point FROM student s JOIN score sc ON sc.student_id s.student_id JOIN course c ON c.course_id sc.course_id;视图定义里没有WHERE意味着它会把全量数据都算出来。数据量小无所谓但如果后续要做分页查询SELECT * FROM vw_student_score WHERE student_id ?在 8.0 上可能触发条件合并下推在 5.7 上则可能先物化整个视图再过滤。判断方法很简单EXPLAIN一下看select_type是不是DERIVED是的话说明视图被物化了。索引要和视图配套建。上面这个视图按student_id过滤成绩表上已经有联合唯一索引(student_id, course_id, term)最左列能用上够了。但课程维度统计某门课的平均分、及格率走的是course_id所以我在成绩表上单独加了idx_course_score (course_id, score)这个索引同时能覆盖“按课程查分数区间”的查询属于覆盖索引回表都省了。联合索引的核心规则是最左前缀(course_id, score)能支持WHERE course_id ?和WHERE course_id ? AND score ?但支持不了单独的WHERE score ?。建索引前先用EXPLAIN看现有查询的key列别凭感觉加。EXPLAIN 列需要关注的值含义typeALL全表扫描数据量大时要处理typeref / range / index可接受分别对应等值、范围、全索引扫描keyNULL没走索引检查是否有隐式转换或函数包列rows远大于结果行数统计信息过期可执行 ANALYZE TABLEExtraUsing filesort排序没走索引考虑把排序列加入联合索引ExtraUsing temporary用了临时表常见于 GROUP BY 没走索引4.2 触发器用数据库层兜住业务规则触发器适合放“无论从哪个入口都必须执行”的规则课程设计里最典型的是选课人数上限和成绩变更留痕。前者用BEFORE INSERT拦截后者用AFTER UPDATE记录。DELIMITER $$ CREATE TRIGGER trg_score_before_insert BEFORE INSERT ON score FOR EACH ROW BEGIN DECLARE cur_cnt INT DEFAULT 0; -- 只对已有成绩的正式选课计数NULL 表示尚未录入成绩 SELECT COUNT(*) INTO cur_cnt FROM score WHERE course_id NEW.course_id; IF cur_cnt 60 THEN -- 自定义错误码 45000 表示用户定义异常前端可直接展示 SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 该课程选课人数已达上限; END IF; -- 成绩范围兜底弥补 5.7 不执行 CHECK 的问题 IF NEW.score IS NOT NULL AND (NEW.score 0 OR NEW.score 100) THEN SIGNAL SQLSTATE 45000 SET MESSAGE_TEXT 成绩必须在 0 到 100 之间; END IF; END$$ DELIMITER ;这段触发器有两个技术点。SIGNAL SQLSTATE 45000是 MySQL 抛自定义错误的固定写法45000属于用户自定义异常段应用层捕获后可以直接把MESSAGE_TEXT展示给用户不用再翻译错误码。第二个点是触发器内部对score表做了COUNT(*)查询——这在BEFORE INSERT里是允许的因为此时行还没写入但如果你在AFTER INSERT里对同一张表做查询就会撞上ERROR 1442 Cant update table in stored function/trigger。触发器的维护成本经常被低估。每加一条业务规则就加一个触发器半年后没人说得清一张表上挂了几个。我的习惯是在建表脚本旁边维护一张注释表记录触发器名、触发时机、对应规则迁移时一起带走。4.3 存储过程与 DELIMITER客户端解析差异是主要坑源存储过程在课程设计里的作用是展示“过程化 SQL 能力”典型题目是“输入课程号输出平均分和及格率”。写法不难难在导入时的分隔符处理。DELIMITER $$ CREATE PROCEDURE sp_course_stat( IN p_course_id VARCHAR(8), OUT p_avg_score DECIMAL(5,2), OUT p_pass_rate DECIMAL(5,2) ) BEGIN SELECT ROUND(AVG(score), 2), ROUND(SUM(CASE WHEN score 60 THEN 1 ELSE 0 END) / NULLIF(COUNT(score), 0) * 100, 2) INTO p_avg_score, p_pass_rate FROM score WHERE course_id p_course_id AND score IS NOT NULL; END$$ DELIMITER ;DELIMITER $$不是 SQL 语句是客户端指令作用是告诉客户端“暂时别用分号切语句”。存储过程体内部有多个分号结尾的语句不换分隔符的话客户端读到第一个分号就把半截CREATE PROCEDURE发到服务器必然报 1064。这里有个容易被忽略的差异命令行客户端mysql file.sql和图形化客户端的“运行 SQL 文件”对DELIMITER的处理不完全一致。有的图形化工具会自己解析分隔符遇到脚本里的DELIMITER反而报错有的则原样透传。稳妥做法是存储过程和触发器单独放一个文件用命令行source或重定向执行别混在图形化工具的多语句执行里。调用时注意OUT参数必须用会话变量接CALL sp_course_stat(CS101, avg, rate); SELECT avg AS avg_score, rate AS pass_rate;如果直接CALL sp_course_stat(CS101, 0, 0)会报参数类型错误。NULLIF(COUNT(score), 0)是为了防止课程没有任何成绩时除零返回NULL而不是报错这个细节在演示时能体现考虑周全。5. 避坑与排查五条跑不动、查不对的血泪记录下面五条都是导入和演示阶段真实会撞上的按“现象、原因、解决”写能直接对照自己的报错信息定位。5.1 外键报 1452初始化数据的插入顺序错了现象执行数据脚本时中断报ERROR 1452 Cannot add or update a child row: a foreign key constraint fails提示某张子表插入的值在父表里不存在。原因数据脚本里的INSERT顺序和建表时的外键依赖相反。比如先插score再插student或者父表数据用了DELETE后重灌但自增 ID 变了。还有一种隐蔽情况父表脚本里INSERT被ON DUPLICATE KEY UPDATE跳过ID 没生成。解决按依赖拓扑排序先父后子。快速定位可以用下面这条查询列出所有外键依赖再对照脚本里的插入顺序。SELECT table_name, constraint_name, referenced_table_name FROM information_schema.key_column_usage WHERE table_schema course_design AND referenced_table_name IS NOT NULL ORDER BY referenced_table_name, table_name;临时排查时可以SET FOREIGN_KEY_CHECKS 0先灌进去但灌完必须改回 1 并跑一遍孤儿数据检查别把关闭外键检查当成常规操作留在脚本里。5.2 中文变问号字符集断在连接层现象表里的中文正常但通过命令行查询或应用写入后显示成???或者报Incorrect string value: \xE5\xAD\xA6...。原因库和表是utf8mb4但连接层是latin1或utf8三字节。MySQL 的字符集是分层级的服务端默认、库、表、列、连接各自独立任何一层窄了都会截断。utf8在 MySQL 里最大三字节存不了 emoji 和部分生僻字。解决连接串里显式指定characterEncodingutf8mb4命令行加--default-character-setutf8mb4脚本头部加SET NAMES utf8mb4。三处都写上别赌哪一层是默认值。检查当前会话用SHOW VARIABLES LIKE character_set%;重点看character_set_client、character_set_connection、character_set_results三个是否都是utf8mb4。5.3 触发器建不上DELIMITER 被客户端吃掉了现象单独执行CREATE TRIGGER语句成功但整个脚本文件导入时在触发器处报 1064错误位置指向触发器体内的第一个分号。原因客户端按分号切分语句DELIMITER指令没生效或被工具忽略。有些图形化工具在执行“运行 SQL 文件”时会自己做语句切分不认脚本里的DELIMITER。解决把触发器和存储过程拆到单独文件用命令行重定向执行或者在图形化工具里改为逐条选中执行。判断是否踩了这个坑看报错行号是不是恰好落在BEGIN之后的第一条语句上。5.4 时间差八小时TIMESTAMP 与 DATETIME 的时区行为不同现象插入时间明明是下午三点查出来是早上七点或者应用和数据库看到的created_at不一致。原因TIMESTAMP存储时按 UTC 转换读取时按会话时区转换DATETIME原样存储不做转换。如果连接层时区是SYSTEM而服务器系统时区不是东八区TIMESTAMP就会偏移。另外 JDBC 连接串里serverTimezone配错也会导致同样现象。解决业务时间字段统一用DATETIME避免隐式时区转换确实需要TIMESTAMP的比如记录最后更新时间做增量同步在连接建立后执行SET time_zone 08:00。排查时对比SELECT NOW(), UTC_TIMESTAMP(), session.time_zone;三个值就能判断偏移来源。5.5 索引没走隐式类型转换和函数包列现象student_id上明明有索引EXPLAIN的type却是ALLkey为NULL。原因两种最常见。一是字段是CHAR但查询条件传了数字MySQL 会把列转成数字比较索引失效二是WHERE DATE(created_at) 2024-09-01这种函数包列索引列被函数处理后就无法直接定位。解决参数类型和列类型保持一致字符串就加引号时间范围查询改写成created_at 2024-09-01 AND created_at 2024-09-02。改完再EXPLAIN一次确认key有值、rows明显下降。这一步在实验报告的“查询优化”小节里放前后对比比空谈理论有说服力得多。6. 把隔离级别跑成可观测实验一份两会话验证脚本课程设计里事务隔离级别这一章光背“脏读、不可重复读、幻读”三个定义答辩时很容易被追问“你怎么验证的”。最省事的办法是开两个命令行会话用同一张表把四种隔离级别的行为跑一遍把结果记成对照表。先建一张只有两列的小表避免干扰CREATE TABLE t_isolation ( id INT PRIMARY KEY, value INT NOT NULL ) ENGINEInnoDB; INSERT INTO t_isolation VALUES (1, 100);会话 A 和会话 B 分别连同一个库。A 执行SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;或REPEATABLE READ然后开启事务并更新-- 会话 A START TRANSACTION; UPDATE t_isolation SET value 200 WHERE id 1; -- 此处不提交保持事务打开此时切到会话 B在READ COMMITTED下查询会读到 100未提交的修改不可见不脏读如果 A 提交后再查B 能读到 200同一事务内两次查询结果不同不可重复读。把 B 的隔离级别改成REPEATABLE READ再走一遍A 提交后 B 仍然读到 100直到 B 自己提交或回滚——这就是快照读的效果。验证幻读要用范围查询。A 在事务里执行SELECT COUNT(*) FROM t_isolation WHERE value 50;B 插入一条value 300并提交A 再查一次。REPEATABLE READ下两次计数一致READ COMMITTED下第二次会多出一条。把这三组结果整理成表格放进报告比抄定义强得多。我踩过一次坑以为改隔离级别只要SET GLOBAL就全局生效结果新开会话还是旧级别。SET GLOBAL只影响之后建立的连接当前会话必须用SET SESSION。从那以后我每次做隔离级别实验都先在两个会话里各执行一次SELECT transaction_isolation;确认级别一致再开始省得跑完一轮发现结论对不上又重来。希望帮到你。本文还有配套的精品资源点击获取

可直接运行的数据库系统概论课程设计包：MySQL导入建表与事务实验避坑

相关推荐

从用例图到双账本：超市进销存系统库存一致性设计

重复文件清理技术：原理、工具与最佳实践

ModelSim老工程救星：GCC 4.2.1 MinGW32 VC9编译包详解与避坑指南

更多资讯

n8n实现电商订单全自动处理工作流设计

SAM一键抠图：零样本图像分割实战指南

SQL Server数据库系统加固规范：11条安全基线落地与验收

JMeter二次开发实战：自定义组件与性能优化

SQL Server数据库加固：账号口令基线与权限最小化检查表

2025 AI安全动荡期：70%攻击源自供应链，如何加固技术栈？

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

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