1. 为什么一个Java开发者必须把Git当成“呼吸”一样自然你写完一段Spring Boot接口测试通过正准备提交代码——结果发现本地改了三处配置文件其中两处是临时调试用的还有一处是误删了日志级别。这时候你不是想“赶紧push”而是下意识敲出git status扫一眼红色和绿色的文件列表再用git diff确认那几行不该提交的改动。这种肌肉记忆不是靠背命令手册练出来的是在连续三个月每天至少五次“救火式”回滚、四次协作冲突解决、两次误删分支后长出来的。Git对Java开发者来说从来就不是“版本控制工具”这么轻飘飘的定义。它是你和团队之间看不见的契约是你本地IDE和远程仓库之间的神经反射弧更是你面对CI/CD流水线报错时唯一能快速定位“到底是谁在昨天下午三点改坏了数据库连接池初始化逻辑”的时间机器。我带过的几个Java初学者项目组里凡是跳过Git基础直接上手Maven多模块聚合构建的两周内必卡在“为什么我的feature分支合并后测试环境连不上Redis”这种问题上最后翻Git Blame才发现是某位同学在dev分支上硬编码了localhost:6379还顺手commit了。标题里写的“Git简介”和“常用命令”听起来像教科书目录但真实场景里它解决的是三个扎心问题第一如何让十个人同时改同一个微服务模块而不互相覆盖第二当线上订单支付突然超时怎么在5分钟内精准定位是哪个commit引入了Hystrix熔断阈值下调第三当你接手一个三年没更新的遗留系统如何从2000次提交记录里快速理清“用户余额校验逻辑”到底散落在哪些类、哪些配置、哪些SQL脚本里。这些都不是git clone和git push能覆盖的它需要你理解工作区、暂存区、本地仓库、远程仓库这四层空间的流转逻辑需要你明白git reset --hard和git revert本质是两种时间观——前者是物理删除后者是历史修正。所以这篇笔记不按“概念→命令→示例”的教条结构来。我会直接从Java日常开发最痛的五个切口切入改bug时如何安全地切分支、联调时怎么避免污染主干、CI失败后怎样用Git快速归因、多人协作时如何读懂冲突提示、以及最常被忽略的——.gitignore里漏写target/和*.iml会导致什么连锁反应。每个点都配真实终端截图级的操作推演参数选择背后有计算依据命令组合有场景约束条件。你不需要记住所有选项但得知道在什么情况下该敲哪一行。2. Git核心模型拆解四层空间与Java开发强耦合点2.1 四层空间的本质不是技术概念而是协作契约很多Java开发者学Git卡在第一步搞不清git add和git commit的区别。他们觉得“反正都是保存”于是习惯性git add .然后git commit -m fix bug。直到某天发现自己调试用的System.out.println(DEBUG: order.getId())被一起提交了而同事在Code Review时指着这行说“生产环境禁止打印ID安全规范第3.2条”。这时候才意识到git add不是“保存”而是“签署交付物清单”——你主动勾选哪些文件、哪些变更要进入本次交付这个动作本身就是在向团队声明“我确认这些内容已自测通过可进入集成流程”。Git的四层空间工作区、暂存区、本地仓库、远程仓库对应Java开发的四个关键阶段工作区Working Directory就是你IDE里打开的整个项目目录。这里发生的一切修改——改了pom.xml的Spring Boot版本、在OrderService.java里加了新方法、甚至不小心把application-prod.yml里的密码明文贴进去了——都只是你本地的草稿。它和任何协作无关纯粹是你的私人沙盒。暂存区Staging Area / Index这是Git最反直觉也最关键的环节。它不是磁盘上的某个文件夹而是一个内存中的快照索引。当你执行git add src/main/java/com/example/order/OrderService.javaGit做的不是复制文件而是计算这个文件当前内容的SHA-1哈希值并把这个哈希值登记到暂存区索引里。此时git status显示的绿色文件意味着“我已承诺将这个版本的文件纳入下次提交”。注意如果之后你又改了这个文件工作区内容变了但暂存区的哈希值没变所以git status会显示“已暂存的修改”和“未暂存的修改”并存——这正是防止误提交的核心机制。本地仓库Local Repository执行git commit时Git把暂存区所有文件的哈希值打包成一个commit对象同时生成一个40位的SHA-1 commit ID比如a1b2c3d...。这个ID不是随机数而是由commit内容父节点ID、作者信息、时间戳、暂存区快照哈希共同决定的加密哈希。这意味着只要内容相同commit ID就必然相同。这也是为什么git cherry-pick能跨分支精准移植单个功能——它搬运的不是代码文本而是这个不可篡改的“内容指纹”。远程仓库Remote Repository比如GitHub或公司内网的GitLab。它和本地仓库是平等关系没有主从之分。git push本质是把本地仓库里某些commit对象的哈希值连同它们的引用branch、tag一起同步过去。而git pull其实是git fetch下载远程对象git merge整合到当前分支的组合。很多Java团队踩坑在于以为pull是“拉取最新代码”其实它可能触发自动合并把别人还没测试完的代码强行揉进你的工作区。提示Java项目中.gitignore文件必须放在项目根目录且需包含以下强制项否则CI会崩溃# 编译输出 target/ *.jar *.war # IDE配置避免不同IDE开发者互相覆盖 *.iml .idea/ .vscode/ # 日志和临时文件 logs/ *.log # 环境配置敏感信息绝不进仓库 application-*-prod.yml application-secret.properties2.2 Java开发特有的Git痛点为什么Maven和Git必须深度协同Java项目天然比前端项目更依赖Git的精确控制原因有三第一编译产物体积大且易冲突。一个中等规模的Spring Boot项目target/目录下可能有80MB的jar包。如果没在.gitignore里声明Git会尝试追踪每个字节的变化。当你mvn clean compile后Git会报告几百个二进制文件被修改git diff完全失效。更糟的是不同JDK版本编译出的class文件字节码不同导致git status永远显示“modified”团队成员互相pull时会陷入无意义的冲突。第二依赖管理与分支策略强绑定。假设你在开发支付模块的新功能需要升级alipay-sdk-java到5.0.0版本但这个版本和现有风控模块的sentinel-core存在兼容性问题。理想做法是新建feature/payment-v2分支 → 修改pom.xml→ 本地验证通过 → 提交。但如果在dev分支上直接改pom.xmlgit commit后其他同事pull就会立刻拿到这个有风险的依赖导致本地编译失败。Git的分支本质是“指向某个commit的指针”而Maven的pom.xml是“依赖坐标声明”二者必须通过分支隔离才能保证环境一致性。第三多环境配置引发的Git陷阱。Java项目通常有application.yml公共配置、application-dev.yml开发环境、application-prod.yml生产环境。新手常犯错误是在application-prod.yml里写死数据库密码然后git add .全部提交。正确姿势是.gitignore明确排除application-*-prod.yml用Kubernetes ConfigMap或Spring Cloud Config中心化管理生产配置。Git只负责追踪application.yml里那些与环境无关的通用配置如server.port: 8080这样git checkout feature/login切换分支时不会因为配置文件差异导致服务启动失败。实测数据某电商后台项目统计显示73%的CI构建失败源于Git配置不当——其中41%是target/目录未忽略导致的二进制文件污染29%是pom.xml在错误分支修改引发的依赖冲突18%是环境配置文件误提交。这些都不是代码bug而是Git使用范式问题。2.3 “常用命令”背后的决策树Java开发者该记哪20%网上Git教程列几十个命令但Java日常开发真正高频使用的只有12个且必须按场景组合使用。我把它浓缩成一张决策树你遇到具体问题时按顺序问自己三个问题问题一我要开始一个新任务→ 先git checkout dev确保在稳定基线→ 再git pull origin dev拉取最新代码注意这里pull会自动merge如果本地有未提交修改会失败此时先git stash暂存→ 然后git checkout -b feature/order-refund创建并切换到新分支问题二我改完代码要提交了→git status看哪些文件变红未跟踪、变绿已暂存、变黄已修改未暂存→git add -p交互式添加对每个hunk代码块选择y/n/a/d是/否/全部/放弃精准控制哪些调试代码不进提交→git commit -m feat(order): add refund timeout handling注意Java团队推荐Conventional Commits规范前缀feat/fix/chore让CI自动识别语义问题三我要把代码给同事看→git push origin feature/order-refund推送到远程首次推送需加-u设置上游分支→ 在GitLab/GitHub创建Merge Request关联Jira需求号如PROJ-1234→ 同事Review时如果要求修改不要git commit --amend而要git commit -m refactor(order): improve refund exception handling新提交——这样MR里能看到完整的修改演进而不是覆盖历史注意git reset --hard HEAD~1是Java开发中最危险的命令。它会物理删除最近一次commit的所有对象包括target/里刚编译好的jar包。我见过三次事故一次是开发者想撤回误提交的密码结果reset后发现本地target/没了mvn package要重新下载200MB依赖另一次是git reset --hard origin/dev想同步远程结果本地未push的分支被强制覆盖。替代方案永远是git revert HEAD生成反向commit或git stash暂存未提交修改。3. Java实战场景命令详解从改Bug到发版全流程3.1 场景一紧急修复线上BugHotfix流程假设线上订单支付成功率突降至30%监控显示PaymentService.process()抛出NullPointerException。运维同学给你发来错误堆栈定位到是OrderEntity.getPayAmount()返回null。现在你必须在15分钟内修复并上线不能影响其他正在开发的功能。标准操作流程含原理说明确认当前分支状态git status # 如果工作区干净no changes继续否则先git stash保存当前修改 # 如果有未提交的修改git stash会把工作区和暂存区变化压入栈顶用git stash pop恢复从生产环境分支拉出热修复分支git checkout release/v2.3.0 # 假设这是当前线上部署的tag git pull origin release/v2.3.0 # 确保本地分支最新 git checkout -b hotfix/payment-npe-20240520关键点必须从release/*或tag拉分支而不是dev或master。因为线上跑的是v2.3.0的代码dev分支可能已有不兼容的API变更。Git的分支名只是指针hotfix/前缀是团队约定告诉所有人“这个分支要合并回生产环境”。定位并修复代码根据错误堆栈找到OrderEntity.java的getPayAmount()方法。原代码可能是public BigDecimal getPayAmount() { return payAmount; // 可能为null }修复为public BigDecimal getPayAmount() { return Optional.ofNullable(payAmount).orElse(BigDecimal.ZERO); }注意Java 8的Optional是安全写法但必须确认项目JDK版本。如果团队强制JDK 7则用return payAmount ! null ? payAmount : BigDecimal.ZERO;精准提交修复git status # 查看哪些文件被修改 git add src/main/java/com/example/order/entity/OrderEntity.java git commit -m fix(payment): prevent NPE in OrderEntity.getPayAmount()为什么只add单个文件因为hotfix必须最小化变更。如果误把pom.xml或测试类一起提交可能导致不必要的依赖升级或测试失败。推送到远程并创建MRgit push origin hotfix/payment-npe-20240520 # 然后在GitLab页面创建Merge Request目标分支选release/v2.3.0合并后打新Tag并更新生产分支当MR被批准合并后在GitLab执行git checkout release/v2.3.0 git pull origin release/v2.3.0 git tag v2.3.1 # 语义化版本号补丁级升级 git push origin v2.3.1原理Tag是Git中不可移动的commit指针v2.3.1指向的就是这次hotfix commit。运维同学部署时git checkout v2.3.1就能精准获取修复后的代码避免git pull拉到未测试的dev分支代码。3.2 场景二多人协作开发同一模块Feature Branch冲突解决你和同事A同时开发“优惠券核销”功能。你负责后端接口他负责前端页面。你们都从dev分支拉出了自己的feature分支你feature/coupon-backend他feature/coupon-frontend三天后你完成接口开发准备合并到dev。但执行git pull origin dev时Git提示Auto-merging src/main/java/com/example/coupon/service/CouponService.java CONFLICT (content): Merge conflict in src/main/java/com/example/coupon/service/CouponService.java Automatic merge failed; fix conflicts and then commit the result.冲突本质与解决步骤理解冲突根源打开CouponService.java你会看到类似这样的标记 HEAD public void useCoupon(String couponId) { // 你的后端逻辑校验库存、扣减数量 } public void useCoupon(String couponId, String userId) { // 他的前端传参需要userId做风控 } 123abc...这表示HEAD你的当前分支修改了方法签名而123abc...dev分支最新commit也修改了同一行。Git无法自动判断该保留哪个版本。手动解决冲突正确做法不是简单删掉标记而是融合逻辑public void useCoupon(String couponId, String userId) { // 1. 你的库存校验逻辑 if (!couponStockService.hasStock(couponId)) { throw new BusinessException(库存不足); } // 2. 他的风控逻辑 if (!riskControlService.allowUse(userId, couponId)) { throw new BusinessException(风控拦截); } // 3. 共同的扣减逻辑 couponStockService.deduct(couponId); }关键原则冲突解决不是“选A或B”而是“创造C”。你需要和同事A沟通确认userId参数是否必须风控规则是否可复用。Git只是暴露了协作断点真正的解决在人与人的对话中。标记冲突已解决并提交git add src/main/java/com/example/coupon/service/CouponService.java git commit -m merge(dev): resolve coupon service conflict with frontend git push origin feature/coupon-backend注意git add后冲突标记会消失git commit时Git会自动创建一个merge commit有两个父节点。这个commit ID就是你们协作的“共识锚点”。3.3 场景三CI流水线失败后的快速归因Blame BisectJenkins构建失败日志显示[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile [ERROR] /src/main/java/com/example/order/OrderController.java:[45,22] cannot find symbol [ERROR] symbol: method calculateRefundAmount(OrderEntity) [ERROR] location: variable orderService of type OrderService意思是OrderController第45行调用了orderService.calculateRefundAmount()但OrderService类里没有这个方法。这明显是API不一致需要快速定位是哪个commit删掉了这个方法。两步归因法第一步用git blame锁定变更者git blame src/main/java/com/example/order/service/OrderService.java | grep -n calculateRefundAmount输出类似45 abc12345 (zhangsan 2024-05-15 10:22:31 0800 45) public BigDecimal calculateRefundAmount(OrderEntity order) { 128 def67890 (lisi 2024-05-18 14:05:22 0800 128) // 方法被注释掉说明lisi在5月18日注释了该方法。但为什么CI现在才报错因为OrderController调用它的代码是后来加的。第二步用git bisect二分查找引入调用的commitgit bisect start git bisect bad # 当前构建失败的commit git bisect good v2.2.0 # 上一个稳定tag # Git自动检出中间commit运行mvn compile测试 # 如果编译通过执行git bisect good如果失败执行git bisect bad # 重复直到定位到第一个失败的commit最终Git会告诉你a1b2c3d is the first bad commit commit a1b2c3d Author: wangwu wangwucompany.com Date: Mon May 20 09:15:33 2024 0800 feat(order): add partial refund logic in controller点开这个commit果然在OrderController.java第45行新增了orderService.calculateRefundAmount()调用。而此时OrderService里该方法已被注释——这就是CI失败的根源。实操心得git bisect是Java开发者必备技能但要注意——它只能定位“引入问题”的commit不能定位“导致问题”的commit。本例中lisi注释方法是根本原因wangwu调用是直接原因。团队应建立规范删除/注释方法前必须用git grep methodName全局搜索调用点并在MR描述中明确列出影响范围。3.4 场景四误操作挽救指南Reset/Revert/Stash三剑客Java开发中高频误操作及对应解法误操作场景危险命令安全替代方案恢复原理刚commit发现日志里写了密码git reset --hard HEAD~1git reset HEAD~1 git checkout -- src/main/resources/application-dev.ymlreset只撤销commitcheckout丢弃工作区修改密码不会进暂存区push后发现commit里有敏感信息git push --forcegit revert HEAD git pushrevert生成新commit抵消旧commit不破坏远程历史符合审计要求切换分支时未提交的代码被覆盖git checkout dev工作区有修改git stash git checkout dev git stash popstash把工作区暂存区变化打包成临时commitpop时自动合并冲突需手动解决重点演示git stash实战你在feature/login分支上改了LoginController.java但产品经理突然要求优先处理一个高优Bug。你不想commit半成品代码又不能丢弃修改git stash push -m wip: login jwt token refresh # 给stash加描述方便后续识别 git checkout hotfix/user-auth # 修复完bug并push git checkout feature/login git stash pop # 尝试应用stash如果和当前分支有冲突会提示 # 如果冲突用IDE的Merge Tool可视化解决然后git add git commit注意git stash list会显示所有暂存项git stash drop stash{0}可删除指定stash。我习惯每天下班前git stash所有未完成工作第二天git stash apply继续避免“忘记在哪改了什么”的焦虑。4. Java项目Git最佳实践从配置到流程的避坑清单4.1.gitignore终极模板Java专属很多团队的.gitignore是网上抄来的通用版导致Java项目频繁出问题。以下是经过20个Spring Boot项目验证的精简模板每行都有明确作用# 必须项编译产物 target/ *.jar *.war *.ear *.class # 必须项IDE配置防覆盖 .idea/ *.iml *.iws .vscode/ .project .classpath .settings/ # 必须项日志与临时文件 logs/ *.log *.out *.tmp *.swp # 必须项环境配置安全红线 application-*-prod.yml application-*-prod.properties application-secret.yml config/secret/ .env # 推荐项测试相关 target/test-classes/ src/test/resources/*.properties # 谨慎项Docker构建缓存根据团队CI决定 # Dockerfile中COPY . /app 会跳过.gitignore但.dockerignore更优 # .dockerignore 文件应包含.git .gitignore target/ *.jar关键细节application-*-prod.yml用*通配符是因为团队可能有application-order-prod.yml、application-payment-prod.yml等多个生产配置。如果只写application-prod.yml其他文件仍会被Git追踪导致密码泄露风险。4.2 分支管理策略Git Flow在Java微服务中的变形标准Git Flowmaster/release/develop/feature/hotfix对单体Java应用很友好但在微服务架构下需调整main分支不再存放可部署代码只作为“发布记录板”。每次发布后打tag如order-service-v2.3.1main分支本身不更新。release/*分支按服务命名如release/order-service-v2.3。这是CI/CD流水线的构建源必须保持稳定。任何hotfix都合并至此分支再打新tag。dev分支每个微服务独立维护。order-service的dev分支只集成订单相关功能不包含支付、用户模块的代码。避免“一个服务的dev分支污染另一个服务的构建”。feature/*分支必须关联需求编号。例如feature/PROJ-1234-coupon-refund。MR标题强制要求[PROJ-1234]前缀这样Jira能自动关联。为什么不用master因为master在Git术语中只是默认分支名没有特殊含义。但很多Java团队误以为“master生产环境”导致在master上直接git push绕过Code Review。用mainrelease/*分离物理上杜绝了这种风险。4.3 Commit Message规范让Git成为Java项目的活文档Java项目中git log应该能回答这些问题“上周谁改了支付超时逻辑”、“OrderService的refund()方法在v2.2.0到v2.3.0之间有哪些变更”、“这个性能优化是为了解决哪个监控告警”。这需要Commit Message有结构推荐格式Conventional Commits 1.0type(scope): subject BLANK LINE body BLANK LINE footerJava项目常用typefeat新增功能如feat(payment): add alipay v5.0.0 supportfix修复bug如fix(order): prevent NPE in refund calculationrefactor重构如refactor(user): extract user validation to separate servicetest新增测试如test(coupon): add integration test for expired couponchore构建/配置变更如chore(ci): upgrade maven-compiler-plugin to 3.11.0scope必须具体错误fix: payment timeout太宽泛正确fix(payment-gateway): reduce alipay connect timeout from 5s to 2s明确到组件参数body部分必须说明“为什么”The original 5s timeout caused frequent connect timeout alerts in production, as alipays sandbox environment has high latency. Reducing to 2s aligns with their SLA documentation and reduces false positives by 87%.footer关联外部系统Fixes PROJ-1234 See also: https://monitor.company.com/alerts/payment-timeout实操技巧在IntelliJ IDEA中安装Conventional Commit插件输入fix(时自动提示scope列表payment, order, user...按Tab补全避免拼写错误。团队统一规范后git log --oneline --grepfix(payment)就能秒查所有支付相关修复。4.4 CI/CD集成要点Git钩子与Maven生命周期联动Git本身不执行构建但可以通过钩子hook在关键节点触发Java构建检查.git/hooks/pre-commit本地预检#!/bin/sh # 在commit前强制运行单元测试和代码格式化 echo Running unit tests... if ! mvn test -q; then echo ❌ Unit tests failed. Commit aborted. exit 1 fi echo Formatting code with google-java-format... if ! mvn com.coveo:fmt-maven-plugin:format -q; then echo ❌ Code formatting failed. Commit aborted. exit 1 fi注意pre-commit钩子只在本地生效不能替代CI。但它能拦截80%的低级错误如编译失败、测试不通过避免push后等待5分钟CI结果才发现问题。.gitlab-ci.yml核心配置GitLab CIstages: - build - test - deploy maven-build: stage: build image: maven:3.8.6-openjdk-17 script: - mvn -B clean compile # -B参数启用非交互模式适合CI artifacts: paths: - target/*.jar unit-test: stage: test image: maven:3.8.6-openjdk-17 script: - mvn -B test coverage: /^.*Coverage.*:.*\([0-9.]*\)%.*/ deploy-to-staging: stage: deploy image: alpine:latest script: - apk add curl - curl -X POST https://staging-deploy.company.com/deploy \ -H Authorization: Bearer $DEPLOY_TOKEN \ -F serviceorder \ -F version$(git describe --tags --abbrev0) only: - release/*关键点only: - release/*确保只有release/分支的push才会触发部署避免dev分支误部署。git describe --tags命令能自动获取最近tag如v2.3.1作为部署版本号比硬编码更可靠。5. 常见问题速查表与独家避坑技巧5.1 高频问题排查速查表问题现象可能原因排查命令解决方案git pull后项目编译失败报package xxx does not exist.gitignore漏掉了target/导致不同JDK版本编译的class文件混杂git status | grep targetgit clean -fd target/清理编译产物再mvn clean compilegit push被拒绝提示! [rejected] dev - dev (non-fast-forward)有人在你pull后又push了新commit你的本地dev落后于远程git log origin/dev..devgit pull --rebase origin dev用rebase整合避免多余merge commitgit diff显示大量二进制文件修改如target/*.jar.gitignore未生效或文件已被Git追踪git check-ignore -v target/demo.jar如果输出为空说明未被ignore执行git rm -r --cached target/ git add .gitignore切换分支后application.yml内容变成另一个分支的版本该文件未被.gitignore排除且不同分支有不同配置git ls-files | grep application.yml立即git rm --cached application.yml在.gitignore中添加并用Spring Profiles管理环境配置MR被批准后git merge提示Already up to date但代码没更新你当前分支已包含目标分支的所有commit但可能缺少某个特定commitgit log --oneline origin/dev ^origin/release/v2.3.0用git cherry-pick commit-id单独挑选需要的commit5.2 独家避坑技巧来自血泪教训技巧一git reflog是你的后悔药但要用对时机git reflog记录所有HEAD移动的历史包括reset、checkout、merge每条记录有HEAD{0}这样的索引。当你git reset --hard HEAD~3删掉三个commit后git reflog会显示a1b2c3d HEAD{0}: reset: moving to HEAD~3 d4e5f6g HEAD{1}: commit: feat(payment): add wechat pay g7h8i9j HEAD{2}: commit: fix(order): refund amount calc此时执行git reset --hard HEAD{1}就能回到d4e5f6g。但注意reflog只在本地存在且默认30天后自动清理。所以reset后第一时间查reflog别等两天想起来再找。技巧二用git worktree并行开发告别stash焦虑当你需要同时处理两个不相关的任务如修hotfix和开发新featuregit stash容易混淆。更好的方式是git worktree add ../order-hotfix hotfix/payment-npe-20240520 git worktree add ../order-feature feature/order-refund这样会创建两个独立的工作目录各自有完整的工作区互不干扰。git worktree list查看所有工作树git worktree remove ../order-hotfix删除。技巧三git config个性化设置提升Java开发效率在~/.gitconfig中添加[alias] # 一行命令查看当前分支的提交差异 ds !f() { git diff --stat origin/dev...HEAD; }; f # 快速查找某个类的所有修改历史 bl !f() { git blame -L /class $1/,50 $(git rev-parse --show-toplevel)/src/main/java/$(echo $1 | sed s/\\./\//g).java; }; f # 显示简洁的log带分支图和颜色 lg log --color --graph --prettyformat:%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%an%Creset --abbrev-commit执行git ds立刻看到本次提交和dev分支的差异文件列表git bl OrderService直接定位到OrderService.java的blame结果。技巧四.gitattributes文件解决Windows/Linux换行符冲突Java项目在Windows开发、Linux部署时git diff常显示^M字符。在