面试官问Session和Token有什么区别一张图会员卡现金比喻彻底拿下这道必考题附图解比喻避坑指南你是不是也这样知道Session存服务端、Token存客户端但面试官一追问“为什么大厂还在用Session”“JWT的致命弱点是什么”“分布式场景下到底选哪个”就答不上来了今天一张图 一个会员卡现金故事 完整原理对比 六道追问彻底拿下这道题。摘要Session和Token是两种主流的身份认证方案。Session是有状态的——服务端存储用户数据客户端只存SessionIDToken是无状态的——用户信息编码在Token本身服务端不存状态验签即可。Session优势在于可控性强可随时作废Token优势在于天生支持分布式和跨域。本文用“会员卡 vs 现金”比喻 完整原理对比 JWT深度解析 6道面试官追问彻底讲透这道网络面试必考题。一句话Session是服务端有状态的“会员卡”Token是客户端自持的“现金”。我是折哥《Java 85题图解版》系列连载中已更新48题建议收藏本系列。每周2-3篇85题通关路线一键追完。点击关注第一时间收到每篇新题推送。上一篇面试官问Cookie和Session有什么区别下一篇预告面试官问什么是JWT待发布全部85题点击查看总目录关注专栏追更不迷路一句话总结Session是服务端有状态的“会员卡”Token是客户端自持的“现金”。Session服务端存用户数据客户端只带一个编号SessionID→ 像会员卡你拿着卡号商家服务端查档案才知道你是谁。有状态可控性强。TokenJWT客户端存加密好的用户信息服务端只解密校验不存状态→ 像现金钱上写着“100元”用户信息商家服务端只验真伪不记名。无状态天然支持分布式。背诵口诀Session有状态控权在服务端Token无状态控权在客户端。核心设计理念Session和Token都是为了解决HTTP无状态问题而演进出的两种认证方案——Session追求可控性Token追求扩展性。 面试还原面试官Session和Token有什么区别你项目里用哪个为什么这是网络面试中必问必考的核心题直接进入正题。 一图看懂Session vs Token 全貌交互流程对比 生活比喻会员卡 vs 现金场景设定你去一家连锁餐厅吃饭需要证明自己是会员身份认证。Session 会员卡 商家账本你拿着会员卡号SessionID卡号本身没有任何你的信息商家服务端有一本账本Session存储记录了每个卡号对应的会员信息每次你报卡号商家查账本才知道你是谁、有什么优惠特点商家可以随时修改或删除你的记录可控性强但每个分店都要共享同一本账本分布式Session共享Token 现金你手里拿着100元钞票Token钞票上直接写着“100元”用户信息自包含商家只验真伪验签不记名、不存账本你可以在任何分店任意服务器使用商家不需要共享账本特点方便、跨店通用天然支持分布式但钱一旦发出去了商家没法让这张钱作废无法主动失效一句话对照Session 会员卡 商家账本服务端有状态Token 现金客户端自持无状态。 核心对比表面试速查版Session vs Token维度SessionTokenJWT状态有状态服务端存储无状态客户端存储存储位置服务器端内存/Redis/DB客户端Header/LocalStorage数据内容用户完整信息自包含HeaderPayloadSignature传递方式Cookie自动携带Authorization头手动携带分布式需要Session共享天然支持跨域支持差依赖Cookie极好不依赖Cookie可控性强随时作废弱有效期内无法作废安全性高数据在服务端中数据在客户端需签名带宽占用小SessionID仅32字节大JWT可能几百字节到几KB适用场景传统Web、后台管理前后端分离、微服务、APP Session与Token核心原理Session有状态认证Session的本质服务端生成唯一sessionId在内存/Redis/数据库中维护映射关系sessionId → { userId, 权限, 登录时间… }并将sessionId放入Cookie默认键名JSESSIONID发给浏览器。工作流程用户登录服务端验证凭证服务端创建Session存储用户数据生成唯一SessionID服务端通过Set-Cookie将SessionID下发给浏览器浏览器自动携带CookieSessionID服务端根据SessionID查Session数据识别用户TokenJWT无状态认证JWT的本质一串经过签名、自包含身份信息的字符串由Header.Payload.Signature三部分通过Base64Url编码后以点号分隔构成。Header令牌类型与签名算法如HS256Payload用户身份、权限、过期时间等信息Signature对Header和Payload用密钥签名确保令牌未被篡改工作流程用户登录服务端验证凭证服务端生成JWT签名返回给客户端客户端存储TokenLocalStorage/SessionStorage后续请求在Authorization头中携带Token服务端验证签名 检查过期️ JWT的致命弱点面试加分项⭐1. 无法主动作废Session方案中用户手机丢了或改了密码服务端直接把Redis里的session删掉秒级生效。JWT方案中Token发出去了就像泼出去的水只要还在有效期内比如2小时拿着旧Token的黑客依然畅通无阻。常见的“补救方案”及其问题方案问题把过期时间设短如5分钟用户每5分钟重新登录一次体验爆炸搞黑名单Blacklist每次请求查RedisJWT的“无状态”优势荡然无存2. 续签Renewal复杂Session续签是无感的——服务端在Redis里顺手把过期时间往后延。JWT的过期时间写死在Payload里想续签必须发一个新的JWT前端需要写拦截器逻辑发现快过期了 → 拿着旧Token换新Token → 重发请求。3. 带宽占用大Session ID只有32个字节。一个包含基本信息的JWT动不动就几百个字节甚至可能达到2.8KB放在Header里每次HTTP请求都多带几百字节。对于亿级流量的系统光是流量成本就是一笔巨款。 Session vs Token 选型指南场景推荐方案原因传统Web应用SSRSession天然依赖Cookie实现简单后台管理系统Session用户量可控安全性要求高前后端分离Token不依赖Cookie跨域友好移动APPToken没有浏览器Cookie机制微服务架构Token无状态天然支持分布式金融/支付系统Session需要随时作废权限第三方API授权Token无状态适合开放平台 高频面试追问6道大厂真题追问1Session和Token最本质的区别是什么回答要点有状态 vs 无状态——Session服务端存数据Token客户端存数据。详细回答Session是有状态的——服务端存储用户数据客户端只带SessionID。Token是无状态的——用户信息编码在Token本身服务端不存状态只做验签。这个本质区别决定了它们在分布式、可控性、安全性等各方面的差异。追问2为什么大厂还在用Session而不是JWT回答要点JWT无法主动作废大厂需要精细控制用户权限。详细回答大厂特别是金融、支付类偏爱Session的核心原因是可控性。Session随时可以作废——用户改密码、手机丢了服务端删除Session即可秒级生效。JWT发出后直到过期前都无法作废。此外JWT还有续签复杂、带宽占用大等隐性成本。追问3Token一定比Session更安全吗回答要点不一定。Session数据在服务端更安全Token依赖签名防篡改但数据可被解码查看。详细回答不一定。Session的数据存储在服务端客户端只有SessionID安全性更高。Token的数据在客户端虽然签名防止篡改但Payload部分是Base64编码的任何人都可以解码查看内容。Token的安全依赖于签名算法的强度和密钥的保护。追问4分布式环境下Session共享有哪些解决方案回答要点三种主流方案——黏性会话、集中存储、改用Token无状态。详细回答黏性会话Sticky Session负载均衡将同一用户请求路由到同一台服务器集中存储使用Redis/Memcached等集中式存储所有服务器共享Session改用Token直接放弃Session改用无状态Token方案追问5JWT为什么不能用来代替Session做登录态回答要点JWT无法主动作废、续签复杂、带宽占用大。详细回答JWT的核心问题是无法主动作废。用户改密码后旧Token在有效期内仍然可用。除此之外JWT还有三个问题续签复杂需要前端写拦截器逻辑带宽占用大JWT比SessionID大几十倍数据实时性差用户信息变更无法实时同步追问6Refresh Token是什么能解决JWT的作废问题吗回答要点Refresh Token用于自动续期但不能彻底解决作废问题。详细回答Refresh Token是JWT方案中用于自动续期的机制。Access Token有效期短如15分钟Refresh Token有效期长如7天。Access Token过期后客户端用Refresh Token换取新的Access Token。但它不能彻底解决作废问题——Refresh Token本身也是Token如果被偷了黑客能无限续杯。要作废Refresh Token最终还是需要服务端存储黑名单又回到了“有状态”的问题。 避坑指南序号错误做法正确做法后果1把JWT当Session用存大量用户信息JWT只存必要标识大数据量走服务端带宽浪费性能下降2在JWT Payload中存敏感信息密码Payload只存非敏感标识信息泄露Base64可解码3分布式下用内存Session用Redis集中存储或Token用户登录状态丢失4Token有效期设得过长合理设置有效期 配合Refresh Token安全风险5认为JWT绝对安全签名防篡改但不防解码忽视Payload可读风险 可运行验证代码JavaSpring Boot中Session的使用// 创建SessionPostMapping(/login)publicStringlogin(HttpServletRequestrequest,Stringusername){HttpSessionsessionrequest.getSession();session.setAttribute(username,username);session.setMaxInactiveInterval(1800);// 30分钟return登录成功;}// 读取SessionGetMapping(/profile)publicStringprofile(HttpServletRequestrequest){HttpSessionsessionrequest.getSession(false);if(sessionnull){return未登录;}return用户: session.getAttribute(username);}// 注销作废SessionPostMapping(/logout)publicStringlogout(HttpServletRequestrequest){HttpSessionsessionrequest.getSession(false);if(session!null){session.invalidate();// 立即作废}return已登出;}JavaJWT的生成与验证jjwt库importio.jsonwebtoken.*;importjava.util.Date;// 生成JWTpublicStringgenerateToken(Stringusername){returnJwts.builder().setSubject(username).setIssuedAt(newDate()).setExpiration(newDate(System.currentTimeMillis()3600000))// 1小时.signWith(SignatureAlgorithm.HS256,secretKey).compact();}// 验证JWTpublicClaimsvalidateToken(Stringtoken){try{returnJwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody();}catch(ExpiredJwtExceptione){// Token已过期}catch(SignatureExceptione){// 签名验证失败}returnnull;}❓ 评论区挑战问题以下关于Session和Token的说法哪一个是错误的// 用户登录后生成JWTStringtokenJwts.builder().setSubject(user123).setExpiration(newDate(System.currentTimeMillis()3600000)).signWith(SignatureAlgorithm.HS256,secret).compact();A. Session是有状态的Token是无状态的B. 分布式环境下Token天然支持Session需要共享C. 用户修改密码后旧的JWT会立即失效D. JWT的Payload部分是Base64编码的可以被解码查看 欢迎在评论区写出你的答案和理由我会在下一篇文章发布后更新本文公布答案及错误选项逐项解析。✅ 答案公布正确答案C. 用户修改密码后旧的JWT会立即失效解析JWT是无状态的服务端不存储任何会话信息Token发出后只要还在有效期内即使修改了密码旧Token仍然有效要让JWT失效只能等待过期或维护黑名单但黑名单破坏了无状态特性选项A正确Session有状态Token无状态选项B正确Token天然支持分布式选项D正确JWT的Payload是Base64编码可被解码查看 总结维度SessionTokenJWT状态有状态无状态存储位置服务端客户端传递方式Cookie自动Authorization手动分布式需共享天然支持可控性强随时作废弱有效期内无法作废带宽小32字节大几百字节-KB适用场景传统Web、后台管理前后端分离、微服务、APP面试官最看重的三个点有状态 vs 无状态Session服务端存数据Token客户端存数据——能说清本质区别JWT的致命弱点无法主动作废——能讲清楚为什么大厂还在用Session选型依据传统Web用Session前后端分离/微服务用Token——能根据场景给出建议 系列导航上一篇面试官问Cookie和Session有什么区别下一篇预告面试官问什么是JWT待发布全部85题点击查看总目录关注专栏每周2-3篇一键追更搭配学习效果更佳本篇图解帮你快速建立知识画面记忆如果想深入理解Session和Token在微服务架构中的完整应用可以配合姊妹系列《Java 100天进阶之路》对应章节一起学从零基础到上岗就业108篇完整学习地图每篇标配生活类比 可运行代码 避坑表 面试高频题 练习题不背八股文真正讲透“为什么”。 《Java 100天进阶之路》完整目录导航学习建议图解系列负责“快速建立知识图谱”进阶系列负责“深入理解原理”两个系列搭配使用面试备考效率翻倍。你们项目用的是Session还是Token遇到过JWT无法作废的坑吗欢迎评论区分享你的故事
面试官问：Session和Token有什么区别？一张图+会员卡现金比喻，彻底拿下这道必考题（附图解+比喻+避坑指南）
面试官问Session和Token有什么区别一张图会员卡现金比喻彻底拿下这道必考题附图解比喻避坑指南你是不是也这样知道Session存服务端、Token存客户端但面试官一追问“为什么大厂还在用Session”“JWT的致命弱点是什么”“分布式场景下到底选哪个”就答不上来了今天一张图 一个会员卡现金故事 完整原理对比 六道追问彻底拿下这道题。摘要Session和Token是两种主流的身份认证方案。Session是有状态的——服务端存储用户数据客户端只存SessionIDToken是无状态的——用户信息编码在Token本身服务端不存状态验签即可。Session优势在于可控性强可随时作废Token优势在于天生支持分布式和跨域。本文用“会员卡 vs 现金”比喻 完整原理对比 JWT深度解析 6道面试官追问彻底讲透这道网络面试必考题。一句话Session是服务端有状态的“会员卡”Token是客户端自持的“现金”。我是折哥《Java 85题图解版》系列连载中已更新48题建议收藏本系列。每周2-3篇85题通关路线一键追完。点击关注第一时间收到每篇新题推送。上一篇面试官问Cookie和Session有什么区别下一篇预告面试官问什么是JWT待发布全部85题点击查看总目录关注专栏追更不迷路一句话总结Session是服务端有状态的“会员卡”Token是客户端自持的“现金”。Session服务端存用户数据客户端只带一个编号SessionID→ 像会员卡你拿着卡号商家服务端查档案才知道你是谁。有状态可控性强。TokenJWT客户端存加密好的用户信息服务端只解密校验不存状态→ 像现金钱上写着“100元”用户信息商家服务端只验真伪不记名。无状态天然支持分布式。背诵口诀Session有状态控权在服务端Token无状态控权在客户端。核心设计理念Session和Token都是为了解决HTTP无状态问题而演进出的两种认证方案——Session追求可控性Token追求扩展性。 面试还原面试官Session和Token有什么区别你项目里用哪个为什么这是网络面试中必问必考的核心题直接进入正题。 一图看懂Session vs Token 全貌交互流程对比 生活比喻会员卡 vs 现金场景设定你去一家连锁餐厅吃饭需要证明自己是会员身份认证。Session 会员卡 商家账本你拿着会员卡号SessionID卡号本身没有任何你的信息商家服务端有一本账本Session存储记录了每个卡号对应的会员信息每次你报卡号商家查账本才知道你是谁、有什么优惠特点商家可以随时修改或删除你的记录可控性强但每个分店都要共享同一本账本分布式Session共享Token 现金你手里拿着100元钞票Token钞票上直接写着“100元”用户信息自包含商家只验真伪验签不记名、不存账本你可以在任何分店任意服务器使用商家不需要共享账本特点方便、跨店通用天然支持分布式但钱一旦发出去了商家没法让这张钱作废无法主动失效一句话对照Session 会员卡 商家账本服务端有状态Token 现金客户端自持无状态。 核心对比表面试速查版Session vs Token维度SessionTokenJWT状态有状态服务端存储无状态客户端存储存储位置服务器端内存/Redis/DB客户端Header/LocalStorage数据内容用户完整信息自包含HeaderPayloadSignature传递方式Cookie自动携带Authorization头手动携带分布式需要Session共享天然支持跨域支持差依赖Cookie极好不依赖Cookie可控性强随时作废弱有效期内无法作废安全性高数据在服务端中数据在客户端需签名带宽占用小SessionID仅32字节大JWT可能几百字节到几KB适用场景传统Web、后台管理前后端分离、微服务、APP Session与Token核心原理Session有状态认证Session的本质服务端生成唯一sessionId在内存/Redis/数据库中维护映射关系sessionId → { userId, 权限, 登录时间… }并将sessionId放入Cookie默认键名JSESSIONID发给浏览器。工作流程用户登录服务端验证凭证服务端创建Session存储用户数据生成唯一SessionID服务端通过Set-Cookie将SessionID下发给浏览器浏览器自动携带CookieSessionID服务端根据SessionID查Session数据识别用户TokenJWT无状态认证JWT的本质一串经过签名、自包含身份信息的字符串由Header.Payload.Signature三部分通过Base64Url编码后以点号分隔构成。Header令牌类型与签名算法如HS256Payload用户身份、权限、过期时间等信息Signature对Header和Payload用密钥签名确保令牌未被篡改工作流程用户登录服务端验证凭证服务端生成JWT签名返回给客户端客户端存储TokenLocalStorage/SessionStorage后续请求在Authorization头中携带Token服务端验证签名 检查过期️ JWT的致命弱点面试加分项⭐1. 无法主动作废Session方案中用户手机丢了或改了密码服务端直接把Redis里的session删掉秒级生效。JWT方案中Token发出去了就像泼出去的水只要还在有效期内比如2小时拿着旧Token的黑客依然畅通无阻。常见的“补救方案”及其问题方案问题把过期时间设短如5分钟用户每5分钟重新登录一次体验爆炸搞黑名单Blacklist每次请求查RedisJWT的“无状态”优势荡然无存2. 续签Renewal复杂Session续签是无感的——服务端在Redis里顺手把过期时间往后延。JWT的过期时间写死在Payload里想续签必须发一个新的JWT前端需要写拦截器逻辑发现快过期了 → 拿着旧Token换新Token → 重发请求。3. 带宽占用大Session ID只有32个字节。一个包含基本信息的JWT动不动就几百个字节甚至可能达到2.8KB放在Header里每次HTTP请求都多带几百字节。对于亿级流量的系统光是流量成本就是一笔巨款。 Session vs Token 选型指南场景推荐方案原因传统Web应用SSRSession天然依赖Cookie实现简单后台管理系统Session用户量可控安全性要求高前后端分离Token不依赖Cookie跨域友好移动APPToken没有浏览器Cookie机制微服务架构Token无状态天然支持分布式金融/支付系统Session需要随时作废权限第三方API授权Token无状态适合开放平台 高频面试追问6道大厂真题追问1Session和Token最本质的区别是什么回答要点有状态 vs 无状态——Session服务端存数据Token客户端存数据。详细回答Session是有状态的——服务端存储用户数据客户端只带SessionID。Token是无状态的——用户信息编码在Token本身服务端不存状态只做验签。这个本质区别决定了它们在分布式、可控性、安全性等各方面的差异。追问2为什么大厂还在用Session而不是JWT回答要点JWT无法主动作废大厂需要精细控制用户权限。详细回答大厂特别是金融、支付类偏爱Session的核心原因是可控性。Session随时可以作废——用户改密码、手机丢了服务端删除Session即可秒级生效。JWT发出后直到过期前都无法作废。此外JWT还有续签复杂、带宽占用大等隐性成本。追问3Token一定比Session更安全吗回答要点不一定。Session数据在服务端更安全Token依赖签名防篡改但数据可被解码查看。详细回答不一定。Session的数据存储在服务端客户端只有SessionID安全性更高。Token的数据在客户端虽然签名防止篡改但Payload部分是Base64编码的任何人都可以解码查看内容。Token的安全依赖于签名算法的强度和密钥的保护。追问4分布式环境下Session共享有哪些解决方案回答要点三种主流方案——黏性会话、集中存储、改用Token无状态。详细回答黏性会话Sticky Session负载均衡将同一用户请求路由到同一台服务器集中存储使用Redis/Memcached等集中式存储所有服务器共享Session改用Token直接放弃Session改用无状态Token方案追问5JWT为什么不能用来代替Session做登录态回答要点JWT无法主动作废、续签复杂、带宽占用大。详细回答JWT的核心问题是无法主动作废。用户改密码后旧Token在有效期内仍然可用。除此之外JWT还有三个问题续签复杂需要前端写拦截器逻辑带宽占用大JWT比SessionID大几十倍数据实时性差用户信息变更无法实时同步追问6Refresh Token是什么能解决JWT的作废问题吗回答要点Refresh Token用于自动续期但不能彻底解决作废问题。详细回答Refresh Token是JWT方案中用于自动续期的机制。Access Token有效期短如15分钟Refresh Token有效期长如7天。Access Token过期后客户端用Refresh Token换取新的Access Token。但它不能彻底解决作废问题——Refresh Token本身也是Token如果被偷了黑客能无限续杯。要作废Refresh Token最终还是需要服务端存储黑名单又回到了“有状态”的问题。 避坑指南序号错误做法正确做法后果1把JWT当Session用存大量用户信息JWT只存必要标识大数据量走服务端带宽浪费性能下降2在JWT Payload中存敏感信息密码Payload只存非敏感标识信息泄露Base64可解码3分布式下用内存Session用Redis集中存储或Token用户登录状态丢失4Token有效期设得过长合理设置有效期 配合Refresh Token安全风险5认为JWT绝对安全签名防篡改但不防解码忽视Payload可读风险 可运行验证代码JavaSpring Boot中Session的使用// 创建SessionPostMapping(/login)publicStringlogin(HttpServletRequestrequest,Stringusername){HttpSessionsessionrequest.getSession();session.setAttribute(username,username);session.setMaxInactiveInterval(1800);// 30分钟return登录成功;}// 读取SessionGetMapping(/profile)publicStringprofile(HttpServletRequestrequest){HttpSessionsessionrequest.getSession(false);if(sessionnull){return未登录;}return用户: session.getAttribute(username);}// 注销作废SessionPostMapping(/logout)publicStringlogout(HttpServletRequestrequest){HttpSessionsessionrequest.getSession(false);if(session!null){session.invalidate();// 立即作废}return已登出;}JavaJWT的生成与验证jjwt库importio.jsonwebtoken.*;importjava.util.Date;// 生成JWTpublicStringgenerateToken(Stringusername){returnJwts.builder().setSubject(username).setIssuedAt(newDate()).setExpiration(newDate(System.currentTimeMillis()3600000))// 1小时.signWith(SignatureAlgorithm.HS256,secretKey).compact();}// 验证JWTpublicClaimsvalidateToken(Stringtoken){try{returnJwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody();}catch(ExpiredJwtExceptione){// Token已过期}catch(SignatureExceptione){// 签名验证失败}returnnull;}❓ 评论区挑战问题以下关于Session和Token的说法哪一个是错误的// 用户登录后生成JWTStringtokenJwts.builder().setSubject(user123).setExpiration(newDate(System.currentTimeMillis()3600000)).signWith(SignatureAlgorithm.HS256,secret).compact();A. Session是有状态的Token是无状态的B. 分布式环境下Token天然支持Session需要共享C. 用户修改密码后旧的JWT会立即失效D. JWT的Payload部分是Base64编码的可以被解码查看 欢迎在评论区写出你的答案和理由我会在下一篇文章发布后更新本文公布答案及错误选项逐项解析。✅ 答案公布正确答案C. 用户修改密码后旧的JWT会立即失效解析JWT是无状态的服务端不存储任何会话信息Token发出后只要还在有效期内即使修改了密码旧Token仍然有效要让JWT失效只能等待过期或维护黑名单但黑名单破坏了无状态特性选项A正确Session有状态Token无状态选项B正确Token天然支持分布式选项D正确JWT的Payload是Base64编码可被解码查看 总结维度SessionTokenJWT状态有状态无状态存储位置服务端客户端传递方式Cookie自动Authorization手动分布式需共享天然支持可控性强随时作废弱有效期内无法作废带宽小32字节大几百字节-KB适用场景传统Web、后台管理前后端分离、微服务、APP面试官最看重的三个点有状态 vs 无状态Session服务端存数据Token客户端存数据——能说清本质区别JWT的致命弱点无法主动作废——能讲清楚为什么大厂还在用Session选型依据传统Web用Session前后端分离/微服务用Token——能根据场景给出建议 系列导航上一篇面试官问Cookie和Session有什么区别下一篇预告面试官问什么是JWT待发布全部85题点击查看总目录关注专栏每周2-3篇一键追更搭配学习效果更佳本篇图解帮你快速建立知识画面记忆如果想深入理解Session和Token在微服务架构中的完整应用可以配合姊妹系列《Java 100天进阶之路》对应章节一起学从零基础到上岗就业108篇完整学习地图每篇标配生活类比 可运行代码 避坑表 面试高频题 练习题不背八股文真正讲透“为什么”。 《Java 100天进阶之路》完整目录导航学习建议图解系列负责“快速建立知识图谱”进阶系列负责“深入理解原理”两个系列搭配使用面试备考效率翻倍。你们项目用的是Session还是Token遇到过JWT无法作废的坑吗欢迎评论区分享你的故事
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
