为何-[NSTextInputClient doCommandBySelector:]不应向上传递不可调用命令？

这个问题问到点子上了——苹果的这条规定看起来有点反直觉，但背后全是为了维护文本编辑的一致性和用户预期，我来给你拆解清楚：

为什么不能调用super或向上传递未处理的命令？ #

首先得回忆NSResponder的默认逻辑：任何 responder 处理不了命令时，都会把消息顺着响应链往上抛（比如从视图到视图控制器，再到窗口、应用）。但对于实现NSTextInputClient的文本视图来说，这种“甩锅”行为会直接破坏文本编辑的体验：

• 文本视图是文本交互的核心：它的职责就是接管所有和文本编辑相关的操作（光标移动、复制粘贴、撤销重做等等）。如果把它处理不了的命令往上传，很可能会被上层对象（比如视图控制器）意外拦截——比如用户在文本框里按Cmd+→想跳到行尾，结果视图控制器的同名命令触发了页面跳转，这完全违背用户预期。
• 非文本命令本就不该由文本视图传递：如果某个命令文本视图处理不了，那大概率不是文本相关的操作。这时候直接忽略就好，因为文本视图作为当前的输入焦点持有者，它“处理不了”就意味着这个命令在当前上下文根本不该执行，上层对象也不需要去处理。

能不能把命令委托给视图控制器？ #

可以，但绝对不能通过调用super或者依赖响应链传递来实现。正确的做法是主动判断并转发：
在文本视图的doCommandBySelector:方法里，先筛选出你需要交给视图控制器处理的自定义命令，直接调用控制器的对应方法；剩下的文本相关命令由文本视图自己处理，无法处理的就直接忽略，不要往上传递。

举个简单的Objective-C示例：

- (void)doCommandBySelector:(SEL)aSelector {
    // 先处理需要委托给视图控制器的自定义命令
    if (aSelector == @selector(triggerCustomAction:)) {
        [self.viewController handleCustomAction];
        return;
    }

    // 处理文本视图原生支持的命令
    if ([self respondsToSelector:aSelector]) {
        [self performSelector:aSelector withObject:nil];
        return;
    }

    // 其他无法处理的命令，直接忽略，不向上传递
}

这只是为了保持macOS应用行为一致吗？ #

不止是一致，更是为了符合用户的操作直觉。macOS系统自带的所有文本组件（比如NSTextView、NSTextField）都严格遵循这条规则，用户在任何文本输入框里操作时，都能预期到快捷键和操作的行为是统一的——不会因为所在页面的控制器不同，就出现“同样的快捷键干不同的事”的情况。这种一致性是macOS系统体验流畅的重要保障。

内容的提问来源于stack exchange，提问作者ctietze