尧图网页设计 
简介面向iOS开发者的轻量示例工程演示如何通过点击按钮移动主视图实现常见的侧滑菜单栏交互。适合需要快速掌握侧滑菜单实现思路的初中级开发者覆盖侧滑视图创建、按钮事件绑定、视图动画切换及自动布局适配等关键环节可作为自定义菜单栏或理解第三方侧滑库原理的入门参考。压缩包共25个文件以Objective-C源码为主包含7个.m实现文件、5个.h头文件另有工程配置plist、pbxproj和本地化strings等文件整体仅36KB结构紧凑便于直接阅读和二次修改。已有198人学习适合在搭建iOS应用框架时参考菜单部分的设计。通过查看源码可快速梳理视图控制器之间的切换逻辑了解如何利用视图变换或坐标调整实现平滑动画并留意状态管理与交互屏蔽细节为独立实现侧滑菜单打下基础。 做iOS开发这些年侧滑菜单栏这个坑我反反复复踩了不下四五个项目。从早期用第三方库拖个控件到后来纯代码手写从简单的左侧抽屉到左右双侧联动再到与UITableView手势冲突的血泪史我算是把这个看似简单的控件彻底摸透了。今天不聊空话就围绕“iOS侧滑菜单栏”这件事从方案选型、核心原理、手写实战到避坑经验完整地过一遍。内容偏干货适合正在写首页框架、想接入抽屉式导航的iOS开发者不管你是用Swift还是Objective-C思路基本通用。1. 从需求到方案侧滑菜单栏为什么值得好好设计1.1 产品层面的场景与设计考量侧滑菜单栏很多人叫它抽屉菜单或者汉堡菜单本质上是一个隐藏的导航容器通过滑动手势或按钮点击把它从屏幕边缘“拖”出来。它在产品设计里承担的任务很明确不占主屏空间、能收纳二级功能入口、并且在一定程度上符合移动端单手操作的习惯。但这里有个容易踩的需求陷阱。同样是侧滑菜单不同产品的交互预期完全不一样。有些产品要做的是“全局导航”菜单覆盖全屏背景蒙层半透明用户点击蒙层关闭菜单像早期的很多新闻类App有些产品做的是“列表操作滑动”比如邮件列表里滑动删除、滑动标星这种交互虽然也叫侧滑但本质是列表项内部的手势操作和抽屉式侧滑菜单完全是两回事。我倾向于在动手写代码之前先明确四个问题菜单是从左侧滑出还是右侧滑出还是左右双侧都有滑出之后主界面需要跟着移动吗还是要使用覆盖式效果菜单是否支持全屏边缘滑动触发还是只能点击汉堡按钮触发宿主页面是在NavigationController栈内还是TabBarController里或者直接是RootViewController这四点直接决定了你后续的技术选型和代码结构千万别上来就写。1.2 技术方案选型手写还是用现成库面对“iOS侧滑菜单栏”这个需求市面上的方案基本分成三类使用成熟的第三方库、使用系统自带容器、纯代码手写。这里我不卖关子直接说我的结论如果项目里只是简单集成一个左侧菜单且不涉及特别复杂的联动手写完全可行甚至更可控如果菜单需要嵌套深层级页面、需要和TabBar做复杂联动可以评估第三方库如果你还顺带要处理iPad多窗口、自定义转场动画那手写几乎是必须的。很多人觉得手写侧滑菜单要处理一堆GestureRecognizer、层级结构、动画参数很麻烦但其实它的核心逻辑并不复杂。关键点在于手写你能清楚地知道每一次位移、每一次回调是谁触发的出了问题能快速定位。第三方库最大的问题恰恰是在这里——它的代码是一个面向通用场景的黑盒一旦你的页面结构稍微特殊一点排查起来非常痛苦。常见的第三方库像SWRevealViewController、SideMenu这些处理通用场景确实很稳但我见过太多项目因为升级系统、适配全面屏之后第三方库表现异常而被迫改造。所以从长远维护的角度看我建议至少具备手写能力哪怕最后你决定用第三方库也能做到心中有数。2. 手写侧滑菜单的核心原理与结构拆解2.1 核心模型一个“会动的容器”侧滑菜单栏的本质是一个视图容器动态变化的过程。你可以把它理解成两个视图菜单视图和后方的内容视图。菜单视图平时藏在屏幕边缘之外通过改变它的frame或者transform把它移动到可视区域内。手写实现时我习惯用一个容器控制器ContainerViewController作为整个侧滑菜单的骨架。这个容器负责三件事持有菜单视图、持有主内容视图、管理两者的展示状态。主内容视图通常是当前选中页面包装成的UINavigationController菜单视图则是一个UIViewController里面可以放TableView、自定义头视图、底部操作区等。这里有一个常见的认知误区菜单栏不是简单往主Window上addSubView。如果你直接把菜单加在Window上状态栏旋转、键盘弹出、页面切换这些场景全都要额外处理非常狼狈。正确的做法是把菜单和内容都放在同一个容器控制器里统一管理生命周期清晰、布局计算也简单。2.2 手势驱动UIPanGestureRecognizer和边缘手势侧滑菜单的手势一般有两个触发入口点击导航栏上的汉堡按钮、屏幕边缘滑动。前者直接用按钮监听事件后者需要加手势识别器。我常用的方案是给内容视图的根视图添加一个UIPanGestureRecognizer通过识别手指平移的距离动态计算菜单视图的位置。核心计算思路是这样的在手指开始移动时记录菜单当前的偏移量在手指移动过程中根据translation.x实时计算目标位置手指结束后根据偏移量是否超过阈值决定展开还是收起并配上弹簧动画。如果要做“只从屏幕边缘触发”的效果建议使用系统提供的UIScreenEdgePanGestureRecognizer并设置edges .left这样能避免与页面内TableView的滚动手势冲突。不过这个手势有个缺点只响应屏幕边缘那一小块区域手滑太深就识别不到。我的经验是优先使用UIScreenEdgePanGestureRecognizer作为边缘触发同时配合导航栏按钮作为确定性入口两者互不冲突。2.3 层级结构与遮罩层级结构上我推荐的顺序是容器控制器的view下面先放主内容视图再放菜单视图最后放一个遮罩按钮或透明视图。遮罩的作用不只是“点了关闭菜单”它有两个职责阻止菜单打开时用户点击主内容区域、在视觉上形成半透明的隔离层。遮罩默认是隐藏的透明度为0菜单展开时遮罩逐渐显示alpha设为0.3左右然后处理点击事件关闭菜单。遮罩不要用UIButton直接用UIView加UITapGestureRecognizer会更灵活因为你可以随时修改它的背景色和透明度交互状态也更直观。3. 用Swift UIKit实现一个可复用的侧滑菜单栏3.1 搭建基础工程结构下面直接上手。我以纯代码 Swift为例搭建一个支持左侧抽屉的侧滑菜单容器。工程结构大致如下SideMenuDemo ├── AppDelegate.swift ├── MainViewController.swift // 入口容器控制器 ├── MenuViewController.swift // 左侧菜单页 ├── HomeViewController.swift // 首页内容控制器 └── SideMenuContainerController.swift // 侧滑菜单容器核心Core是SideMenuContainerController它对外提供一个方法配置菜单控制器和主控制器对内管理手势、动画和状态。我要强调一下容器控制器需要是自定义的UIViewController而不是直接继承UINavigationController或UITabBarController因为侧滑的动画效果由我们自己控制系统容器反而碍事。3.2 编写主容器控制器代码新建SideMenuContainerController关键属性和初始化方法这样写class SideMenuContainerController: UIViewController { enum MenuState { case closed case open } private var menuViewController: UIViewController private var contentViewController: UIViewController private var menuWidth: CGFloat UIScreen.main.bounds.width * 0.75 private var currentState: MenuState .closed private let menuContainerView UIView() private let contentContainerView UIView() private let overlayView UIView() init(menuViewController: UIViewController, contentViewController: UIViewController) { self.menuViewController menuViewController self.contentViewController contentViewController super.init(nibName: nil, bundle: nil) } required init?(coder: NSCoder) { fatalError(init(coder:) has not been implemented) } override func viewDidLoad() { super.viewDidLoad() setupViews() setupGestures() } private func setupViews() { view.backgroundColor .systemBackground contentContainerView.frame view.bounds contentContainerView.autoresizingMask [.flexibleWidth, .flexibleHeight] view.addSubview(contentContainerView) addChild(contentViewController) contentViewController.view.frame contentContainerView.bounds contentViewController.view.autoresizingMask [.flexibleWidth, .flexibleHeight] contentContainerView.addSubview(contentViewController.view) contentViewController.didMove(toParent: self) menuContainerView.frame CGRect(x: -menuWidth, y: 0, width: menuWidth, height: view.bounds.height) menuContainerView.autoresizingMask [.flexibleHeight] view.addSubview(menuContainerView) addChild(menuViewController) menuViewController.view.frame menuContainerView.bounds menuContainerView.addSubview(menuViewController.view) menuViewController.didMove(toParent: self) overlayView.frame view.bounds overlayView.backgroundColor UIColor.black.withAlphaComponent(0.3) overlayView.alpha 0 overlayView.isUserInteractionEnabled false view.addSubview(overlayView) } }一开始把菜单视图的x坐标设置为负的宽度让它藏在屏幕左侧看不见的区域。主内容视图直接铺满全屏菜单视图盖在主内容之上。层级关系到这里已经很清楚。3.3 菜单宽度、偏移计算和弹簧动画菜单宽度建议按屏幕宽度比例计算不要写死。iPhone竖屏下75%的宽度视觉上最舒服既能展示内容又不会完全挡住背景。实际项目里宽度最好做成可配置属性。展开菜单时我使用UIView.animate(withDuration:dampingRatio:)来提供弹簧效果。直接使用transform会比修改frame更丝滑因为transform不触发layoutSubviews性能更好。具体实现private func openMenu(animated: Bool true) { currentState .open overlayView.isUserInteractionEnabled true let targetTransform CGAffineTransform(translationX: menuWidth, y: 0) UIView.animate(withDuration: 0.35, delay: 0, usingSpringWithDamping: 0.85, initialSpringVelocity: 0.5, options: [.curveEaseInOut]) { self.menuContainerView.transform targetTransform self.overlayView.alpha 1 } } private func closeMenu(animated: Bool true) { currentState .closed overlayView.isUserInteractionEnabled false UIView.animate(withDuration: 0.3, delay: 0, usingSpringWithDamping: 0.9, initialSpringVelocity: 0.3, options: [.curveEaseInOut]) { self.menuContainerView.transform .identity self.overlayView.alpha 0 } }注意菜单容器视图的transform是基于它自身原始位置的原始位置是x -menuWidth所以transform之后菜单会向右平移menuWidth最终停靠在屏幕左侧0点。主内容视图不需要移动这样形成的是覆盖式效果。如果你想让主内容跟着向右推就需要把contentContainerView.transform也设置一下但一般产品不会用这种做法覆盖式更轻量也更符合iOS的原生气质。3.4 点击遮罩关闭与状态管理遮罩的点击事件比较简单在setupGestures里添加UITapGestureRecognizer点击后调用closeMenu。状态管理我建议用一个枚举currentState在整个容器里全局维护方便其他模块查询菜单当前是打开还是关闭。比如点击菜单里的某个入口后一般需要先关闭菜单再跳转页面这时在MenuViewController里通过闭包或代理回调容器让容器执行closeMenu并切换主内容。我比较推荐的方案是给SideMenuContainerController加一个切换内容页的方法func setContentViewController(_ newContentViewController: UIViewController) { contentViewController.willMove(toParent: nil) contentViewController.view.removeFromSuperview() contentViewController.removeFromParent() contentViewController newContentViewController addChild(contentViewController) contentViewController.view.frame contentContainerView.bounds contentViewController.view.autoresizingMask [.flexibleWidth, .flexibleHeight] contentContainerView.addSubview(contentViewController.view) contentViewController.didMove(toParent: self) closeMenu() }这样做的好处是菜单选中项和内容页切换被封装在同一个方法里业务方不需要关心侧滑菜单内部实现。切换动画、页面加载顺序都能在这个方法里统一控制。4. 实战避坑那些隐藏的坑我替你踩过了4.1 UINavigationController返回手势冲突这是侧滑菜单在实战中遇到的最典型问题。如果你的内容页面是一个UINavigationController且界面有系统自带的边缘返回手势也就是从屏幕左边缘右滑返回上一级它和菜单的侧滑手势会“打架”。为什么冲突因为系统返回手势UIScreenEdgePanGestureRecognizer也是从左边缘识别两个边缘手势同时存在时系统会根据手势识别的规则决定谁优先。我的解决方案是在内容页的导航栈深度大于1时暂时禁用菜单边缘手势等于1时重新启用菜单边缘手势。也就是说只有当前页面处于根页面时侧滑菜单才允许通过边缘手势呼出其他情况优先让系统返回。代码上可以直接在容器里监听内容页的viewControllers数量然后动态调整侧滑手势的isEnabled。实际项目中效果很好不会让用户觉得手势失灵。4.2 侧滑时TableView的手势抢夺菜单页里如果放了UITableView侧滑菜单的平移手势和TableView的滚动手势会互相抢。常见表现是用户在菜单里上下滚动时菜单偶尔跟着左右抖一下或者在菜单还没完全打开时上下滑动菜单卡在半路。我的处理思路有两个一是给平移手势设置delegate实现gestureRecognizerShouldBegin根据手势方向判断只响应水平方向上的拖动二是如果发现菜单内需要复杂的列表交互可以在菜单完全打开后禁用容器的手势改为只依赖遮罩点击和按钮关闭避免TableView滚动干扰。方向判断的核心逻辑大概是这样func gestureRecognizerShouldBegin(_ gestureRecognizer: UIGestureRecognizer) - Bool { if let pan gestureRecognizer as? UIPanGestureRecognizer { let velocity pan.velocity(in: view) return abs(velocity.x) abs(velocity.y) } return true }只响应水平方向垂直方向的滑动全部交给子视图处理。这套方案我实测在复杂页面上很稳基本没有出现过手势“穿透”的问题。4.3 iPhone全面屏、状态栏和刘海区域适配全面屏出现后侧滑菜单在适配上的坑多了不少。菜单里的内容顶部如果直接顶到安全区外时间、信号这些系统元素会和菜单名称叠在一起非常难看。我的做法是在MenuViewController的view内部使用safeAreaLayoutGuide布局顶部和底部约束不要用固定的高度或坐标。另外菜单从边缘滑出时默认UIViewController的preferredStatusBarStyle会影响状态栏颜色。当菜单打开时你通常希望状态栏变成白色或隐藏关闭时恢复原样。可以在容器控制器里重写childForStatusBarStyle和prefersStatusBarHidden根据currentState返回不同的值这样状态栏切换就不会突兀。4.4 常见问题速查表我把实际开发里遇到过、也在网上看到过的典型问题整理成一张速查表方便你对照排查。问题现象核心原因解决方案菜单打开后点击遮罩不关闭遮罩被其他视图覆盖或者遮罩的isUserInteractionEnabled为false确认遮罩在视图层级的最上层打开时设置isUserInteractionEnabled true菜单里点击选项页面切换后菜单还耷拉在半中央切换逻辑没调用关闭菜单方法或者动画被新页面中断在setContentViewController末尾统一调用closeMenu左边缘手势偶尔没反应与系统返回手势冲突根据导航栈深度动态启用/禁用边缘手势菜单横竖屏切换后位置不对菜单宽度固定、没有重新计算监听屏幕旋转在viewWillTransition中重新布局menuWidth并调整transform菜单滚动列表时主内容也跟着偏移平移手势没有做方向判断在手势代理中拦截垂直方向滑动只响应水平方向打开菜单后状态栏颜色不对容器控制器没有正确代理statusBarStyle重写childForStatusBarStyle让容器决定状态栏样式最后的经验与一个小技巧做完这么多侧滑菜单项目我最大的体会是侧滑菜单真正难的地方不是“把它写出来”而是“把它写稳”。一个稳定的侧滑菜单需要你对视图层级、手势优先级、控制器生命周期都有清晰的理解缺一不可。最后再分享一个我常用来排查手势问题的技巧如果菜单区域手势乱跳你可以在手势回调里临时打印state和location快速定位是哪个手势在抢占。尤其是UIGestureRecognizerDelegate的shouldRecognizeSimultaneouslyWith方法往往能解决许多看似诡异的联动问题。把代理方法实现好比堆一堆手势互斥代码靠谱得多。本文还有配套的精品资源点击获取 iOS侧滑菜单栏手写实战：从原理剖析到手势冲突避坑指南
简介面向iOS开发者的轻量示例工程演示如何通过点击按钮移动主视图实现常见的侧滑菜单栏交互。适合需要快速掌握侧滑菜单实现思路的初中级开发者覆盖侧滑视图创建、按钮事件绑定、视图动画切换及自动布局适配等关键环节可作为自定义菜单栏或理解第三方侧滑库原理的入门参考。压缩包共25个文件以Objective-C源码为主包含7个.m实现文件、5个.h头文件另有工程配置plist、pbxproj和本地化strings等文件整体仅36KB结构紧凑便于直接阅读和二次修改。已有198人学习适合在搭建iOS应用框架时参考菜单部分的设计。通过查看源码可快速梳理视图控制器之间的切换逻辑了解如何利用视图变换或坐标调整实现平滑动画并留意状态管理与交互屏蔽细节为独立实现侧滑菜单打下基础。 做iOS开发这些年侧滑菜单栏这个坑我反反复复踩了不下四五个项目。从早期用第三方库拖个控件到后来纯代码手写从简单的左侧抽屉到左右双侧联动再到与UITableView手势冲突的血泪史我算是把这个看似简单的控件彻底摸透了。今天不聊空话就围绕“iOS侧滑菜单栏”这件事从方案选型、核心原理、手写实战到避坑经验完整地过一遍。内容偏干货适合正在写首页框架、想接入抽屉式导航的iOS开发者不管你是用Swift还是Objective-C思路基本通用。1. 从需求到方案侧滑菜单栏为什么值得好好设计1.1 产品层面的场景与设计考量侧滑菜单栏很多人叫它抽屉菜单或者汉堡菜单本质上是一个隐藏的导航容器通过滑动手势或按钮点击把它从屏幕边缘“拖”出来。它在产品设计里承担的任务很明确不占主屏空间、能收纳二级功能入口、并且在一定程度上符合移动端单手操作的习惯。但这里有个容易踩的需求陷阱。同样是侧滑菜单不同产品的交互预期完全不一样。有些产品要做的是“全局导航”菜单覆盖全屏背景蒙层半透明用户点击蒙层关闭菜单像早期的很多新闻类App有些产品做的是“列表操作滑动”比如邮件列表里滑动删除、滑动标星这种交互虽然也叫侧滑但本质是列表项内部的手势操作和抽屉式侧滑菜单完全是两回事。我倾向于在动手写代码之前先明确四个问题菜单是从左侧滑出还是右侧滑出还是左右双侧都有滑出之后主界面需要跟着移动吗还是要使用覆盖式效果菜单是否支持全屏边缘滑动触发还是只能点击汉堡按钮触发宿主页面是在NavigationController栈内还是TabBarController里或者直接是RootViewController这四点直接决定了你后续的技术选型和代码结构千万别上来就写。1.2 技术方案选型手写还是用现成库面对“iOS侧滑菜单栏”这个需求市面上的方案基本分成三类使用成熟的第三方库、使用系统自带容器、纯代码手写。这里我不卖关子直接说我的结论如果项目里只是简单集成一个左侧菜单且不涉及特别复杂的联动手写完全可行甚至更可控如果菜单需要嵌套深层级页面、需要和TabBar做复杂联动可以评估第三方库如果你还顺带要处理iPad多窗口、自定义转场动画那手写几乎是必须的。很多人觉得手写侧滑菜单要处理一堆GestureRecognizer、层级结构、动画参数很麻烦但其实它的核心逻辑并不复杂。关键点在于手写你能清楚地知道每一次位移、每一次回调是谁触发的出了问题能快速定位。第三方库最大的问题恰恰是在这里——它的代码是一个面向通用场景的黑盒一旦你的页面结构稍微特殊一点排查起来非常痛苦。常见的第三方库像SWRevealViewController、SideMenu这些处理通用场景确实很稳但我见过太多项目因为升级系统、适配全面屏之后第三方库表现异常而被迫改造。所以从长远维护的角度看我建议至少具备手写能力哪怕最后你决定用第三方库也能做到心中有数。2. 手写侧滑菜单的核心原理与结构拆解2.1 核心模型一个“会动的容器”侧滑菜单栏的本质是一个视图容器动态变化的过程。你可以把它理解成两个视图菜单视图和后方的内容视图。菜单视图平时藏在屏幕边缘之外通过改变它的frame或者transform把它移动到可视区域内。手写实现时我习惯用一个容器控制器ContainerViewController作为整个侧滑菜单的骨架。这个容器负责三件事持有菜单视图、持有主内容视图、管理两者的展示状态。主内容视图通常是当前选中页面包装成的UINavigationController菜单视图则是一个UIViewController里面可以放TableView、自定义头视图、底部操作区等。这里有一个常见的认知误区菜单栏不是简单往主Window上addSubView。如果你直接把菜单加在Window上状态栏旋转、键盘弹出、页面切换这些场景全都要额外处理非常狼狈。正确的做法是把菜单和内容都放在同一个容器控制器里统一管理生命周期清晰、布局计算也简单。2.2 手势驱动UIPanGestureRecognizer和边缘手势侧滑菜单的手势一般有两个触发入口点击导航栏上的汉堡按钮、屏幕边缘滑动。前者直接用按钮监听事件后者需要加手势识别器。我常用的方案是给内容视图的根视图添加一个UIPanGestureRecognizer通过识别手指平移的距离动态计算菜单视图的位置。核心计算思路是这样的在手指开始移动时记录菜单当前的偏移量在手指移动过程中根据translation.x实时计算目标位置手指结束后根据偏移量是否超过阈值决定展开还是收起并配上弹簧动画。如果要做“只从屏幕边缘触发”的效果建议使用系统提供的UIScreenEdgePanGestureRecognizer并设置edges .left这样能避免与页面内TableView的滚动手势冲突。不过这个手势有个缺点只响应屏幕边缘那一小块区域手滑太深就识别不到。我的经验是优先使用UIScreenEdgePanGestureRecognizer作为边缘触发同时配合导航栏按钮作为确定性入口两者互不冲突。2.3 层级结构与遮罩层级结构上我推荐的顺序是容器控制器的view下面先放主内容视图再放菜单视图最后放一个遮罩按钮或透明视图。遮罩的作用不只是“点了关闭菜单”它有两个职责阻止菜单打开时用户点击主内容区域、在视觉上形成半透明的隔离层。遮罩默认是隐藏的透明度为0菜单展开时遮罩逐渐显示alpha设为0.3左右然后处理点击事件关闭菜单。遮罩不要用UIButton直接用UIView加UITapGestureRecognizer会更灵活因为你可以随时修改它的背景色和透明度交互状态也更直观。3. 用Swift UIKit实现一个可复用的侧滑菜单栏3.1 搭建基础工程结构下面直接上手。我以纯代码 Swift为例搭建一个支持左侧抽屉的侧滑菜单容器。工程结构大致如下SideMenuDemo ├── AppDelegate.swift ├── MainViewController.swift // 入口容器控制器 ├── MenuViewController.swift // 左侧菜单页 ├── HomeViewController.swift // 首页内容控制器 └── SideMenuContainerController.swift // 侧滑菜单容器核心Core是SideMenuContainerController它对外提供一个方法配置菜单控制器和主控制器对内管理手势、动画和状态。我要强调一下容器控制器需要是自定义的UIViewController而不是直接继承UINavigationController或UITabBarController因为侧滑的动画效果由我们自己控制系统容器反而碍事。3.2 编写主容器控制器代码新建SideMenuContainerController关键属性和初始化方法这样写class SideMenuContainerController: UIViewController { enum MenuState { case closed case open } private var menuViewController: UIViewController private var contentViewController: UIViewController private var menuWidth: CGFloat UIScreen.main.bounds.width * 0.75 private var currentState: MenuState .closed private let menuContainerView UIView() private let contentContainerView UIView() private let overlayView UIView() init(menuViewController: UIViewController, contentViewController: UIViewController) { self.menuViewController menuViewController self.contentViewController contentViewController super.init(nibName: nil, bundle: nil) } required init?(coder: NSCoder) { fatalError(init(coder:) has not been implemented) } override func viewDidLoad() { super.viewDidLoad() setupViews() setupGestures() } private func setupViews() { view.backgroundColor .systemBackground contentContainerView.frame view.bounds contentContainerView.autoresizingMask [.flexibleWidth, .flexibleHeight] view.addSubview(contentContainerView) addChild(contentViewController) contentViewController.view.frame contentContainerView.bounds contentViewController.view.autoresizingMask [.flexibleWidth, .flexibleHeight] contentContainerView.addSubview(contentViewController.view) contentViewController.didMove(toParent: self) menuContainerView.frame CGRect(x: -menuWidth, y: 0, width: menuWidth, height: view.bounds.height) menuContainerView.autoresizingMask [.flexibleHeight] view.addSubview(menuContainerView) addChild(menuViewController) menuViewController.view.frame menuContainerView.bounds menuContainerView.addSubview(menuViewController.view) menuViewController.didMove(toParent: self) overlayView.frame view.bounds overlayView.backgroundColor UIColor.black.withAlphaComponent(0.3) overlayView.alpha 0 overlayView.isUserInteractionEnabled false view.addSubview(overlayView) } }一开始把菜单视图的x坐标设置为负的宽度让它藏在屏幕左侧看不见的区域。主内容视图直接铺满全屏菜单视图盖在主内容之上。层级关系到这里已经很清楚。3.3 菜单宽度、偏移计算和弹簧动画菜单宽度建议按屏幕宽度比例计算不要写死。iPhone竖屏下75%的宽度视觉上最舒服既能展示内容又不会完全挡住背景。实际项目里宽度最好做成可配置属性。展开菜单时我使用UIView.animate(withDuration:dampingRatio:)来提供弹簧效果。直接使用transform会比修改frame更丝滑因为transform不触发layoutSubviews性能更好。具体实现private func openMenu(animated: Bool true) { currentState .open overlayView.isUserInteractionEnabled true let targetTransform CGAffineTransform(translationX: menuWidth, y: 0) UIView.animate(withDuration: 0.35, delay: 0, usingSpringWithDamping: 0.85, initialSpringVelocity: 0.5, options: [.curveEaseInOut]) { self.menuContainerView.transform targetTransform self.overlayView.alpha 1 } } private func closeMenu(animated: Bool true) { currentState .closed overlayView.isUserInteractionEnabled false UIView.animate(withDuration: 0.3, delay: 0, usingSpringWithDamping: 0.9, initialSpringVelocity: 0.3, options: [.curveEaseInOut]) { self.menuContainerView.transform .identity self.overlayView.alpha 0 } }注意菜单容器视图的transform是基于它自身原始位置的原始位置是x -menuWidth所以transform之后菜单会向右平移menuWidth最终停靠在屏幕左侧0点。主内容视图不需要移动这样形成的是覆盖式效果。如果你想让主内容跟着向右推就需要把contentContainerView.transform也设置一下但一般产品不会用这种做法覆盖式更轻量也更符合iOS的原生气质。3.4 点击遮罩关闭与状态管理遮罩的点击事件比较简单在setupGestures里添加UITapGestureRecognizer点击后调用closeMenu。状态管理我建议用一个枚举currentState在整个容器里全局维护方便其他模块查询菜单当前是打开还是关闭。比如点击菜单里的某个入口后一般需要先关闭菜单再跳转页面这时在MenuViewController里通过闭包或代理回调容器让容器执行closeMenu并切换主内容。我比较推荐的方案是给SideMenuContainerController加一个切换内容页的方法func setContentViewController(_ newContentViewController: UIViewController) { contentViewController.willMove(toParent: nil) contentViewController.view.removeFromSuperview() contentViewController.removeFromParent() contentViewController newContentViewController addChild(contentViewController) contentViewController.view.frame contentContainerView.bounds contentViewController.view.autoresizingMask [.flexibleWidth, .flexibleHeight] contentContainerView.addSubview(contentViewController.view) contentViewController.didMove(toParent: self) closeMenu() }这样做的好处是菜单选中项和内容页切换被封装在同一个方法里业务方不需要关心侧滑菜单内部实现。切换动画、页面加载顺序都能在这个方法里统一控制。4. 实战避坑那些隐藏的坑我替你踩过了4.1 UINavigationController返回手势冲突这是侧滑菜单在实战中遇到的最典型问题。如果你的内容页面是一个UINavigationController且界面有系统自带的边缘返回手势也就是从屏幕左边缘右滑返回上一级它和菜单的侧滑手势会“打架”。为什么冲突因为系统返回手势UIScreenEdgePanGestureRecognizer也是从左边缘识别两个边缘手势同时存在时系统会根据手势识别的规则决定谁优先。我的解决方案是在内容页的导航栈深度大于1时暂时禁用菜单边缘手势等于1时重新启用菜单边缘手势。也就是说只有当前页面处于根页面时侧滑菜单才允许通过边缘手势呼出其他情况优先让系统返回。代码上可以直接在容器里监听内容页的viewControllers数量然后动态调整侧滑手势的isEnabled。实际项目中效果很好不会让用户觉得手势失灵。4.2 侧滑时TableView的手势抢夺菜单页里如果放了UITableView侧滑菜单的平移手势和TableView的滚动手势会互相抢。常见表现是用户在菜单里上下滚动时菜单偶尔跟着左右抖一下或者在菜单还没完全打开时上下滑动菜单卡在半路。我的处理思路有两个一是给平移手势设置delegate实现gestureRecognizerShouldBegin根据手势方向判断只响应水平方向上的拖动二是如果发现菜单内需要复杂的列表交互可以在菜单完全打开后禁用容器的手势改为只依赖遮罩点击和按钮关闭避免TableView滚动干扰。方向判断的核心逻辑大概是这样func gestureRecognizerShouldBegin(_ gestureRecognizer: UIGestureRecognizer) - Bool { if let pan gestureRecognizer as? UIPanGestureRecognizer { let velocity pan.velocity(in: view) return abs(velocity.x) abs(velocity.y) } return true }只响应水平方向垂直方向的滑动全部交给子视图处理。这套方案我实测在复杂页面上很稳基本没有出现过手势“穿透”的问题。4.3 iPhone全面屏、状态栏和刘海区域适配全面屏出现后侧滑菜单在适配上的坑多了不少。菜单里的内容顶部如果直接顶到安全区外时间、信号这些系统元素会和菜单名称叠在一起非常难看。我的做法是在MenuViewController的view内部使用safeAreaLayoutGuide布局顶部和底部约束不要用固定的高度或坐标。另外菜单从边缘滑出时默认UIViewController的preferredStatusBarStyle会影响状态栏颜色。当菜单打开时你通常希望状态栏变成白色或隐藏关闭时恢复原样。可以在容器控制器里重写childForStatusBarStyle和prefersStatusBarHidden根据currentState返回不同的值这样状态栏切换就不会突兀。4.4 常见问题速查表我把实际开发里遇到过、也在网上看到过的典型问题整理成一张速查表方便你对照排查。问题现象核心原因解决方案菜单打开后点击遮罩不关闭遮罩被其他视图覆盖或者遮罩的isUserInteractionEnabled为false确认遮罩在视图层级的最上层打开时设置isUserInteractionEnabled true菜单里点击选项页面切换后菜单还耷拉在半中央切换逻辑没调用关闭菜单方法或者动画被新页面中断在setContentViewController末尾统一调用closeMenu左边缘手势偶尔没反应与系统返回手势冲突根据导航栈深度动态启用/禁用边缘手势菜单横竖屏切换后位置不对菜单宽度固定、没有重新计算监听屏幕旋转在viewWillTransition中重新布局menuWidth并调整transform菜单滚动列表时主内容也跟着偏移平移手势没有做方向判断在手势代理中拦截垂直方向滑动只响应水平方向打开菜单后状态栏颜色不对容器控制器没有正确代理statusBarStyle重写childForStatusBarStyle让容器决定状态栏样式最后的经验与一个小技巧做完这么多侧滑菜单项目我最大的体会是侧滑菜单真正难的地方不是“把它写出来”而是“把它写稳”。一个稳定的侧滑菜单需要你对视图层级、手势优先级、控制器生命周期都有清晰的理解缺一不可。最后再分享一个我常用来排查手势问题的技巧如果菜单区域手势乱跳你可以在手势回调里临时打印state和location快速定位是哪个手势在抢占。尤其是UIGestureRecognizerDelegate的shouldRecognizeSimultaneouslyWith方法往往能解决许多看似诡异的联动问题。把代理方法实现好比堆一堆手势互斥代码靠谱得多。本文还有配套的精品资源点击获取