Recent business reasons. To use TP6 events, there was a vague concept before. Take a thorough look today, according to the official documents

Define events

The event system uses the observer mode to provide a better way to understand the application

First, you need to generate an event class, which can be generated using the official command

php think make:event UserLogin

After running, the command will generate the app\evect\UserLogin.php file as the event class

After generation, bind to bind the event class in app\evevt.php. Officially, it can be more concise. I tried it. It's true

<?php
// Event definition file
return [
    'bind'      => [
        //When you are not bound here, you need to trigger events in the controller
        //Event::trigger('UserLogin');  
        //But if you bind it, you can write it as follows. In this way, when the controller calls, you can write it as
        //Event::trigger('U');
        //I guess that's it. I didn't study it specifically.
        'U' => 'UserLogin',
    ],

    'listen'    => [
        'AppInit'  => [],
        'HttpRun'  => [],
        'HttpEnd'  => [],
        'LogLevel' => [],
        'LogWrite' => [],
    ],

    'subscribe' => [
    ],
];

Because only testing does not do relevant model operations, but only do basic output to see the process, so I wrote a method echo

app\evect\UserLogin.php 

<?php
declare (strict_types = 1);

namespace app\event;

class UserLogin
{
    public function index()
    {
        return 'Here is the event class'.'<br/>';
    }
}

  At the same time, a listening class should be generated to listen to the business logic of events. The two are combined. The listening class is used to listen and trigger events. The following command will generate app\listener\UserLogin file as the listening class

php think make:listener UserLogin

After creation, you need to register for binding. If you do not bind, you can also perform dynamic registration. The manual registration is written as in the controller

Event::listen('UserLogin','app\listener\UserLogin');

<?php
// Event definition file
return [
    'bind'      => [
        //When you are not bound here, you need to trigger in the controller
        //Event::trigger('UserLogin');  
        //But if you bind it, you can write it as follows. In this way, when the controller calls, you can write it as
        //Event::trigger('U');
        //I guess that's it. I didn't study it specifically.
        'U' => 'UserLogin',
    ],

    'listen'    => [
        'UserLogin' => app\listener\UserLogin,
        'AppInit'  => [],
        'HttpRun'  => [],
        'HttpEnd'  => [],
        'LogLevel' => [],
        'LogWrite' => [],
    ],

    'subscribe' => [
    ],
];

  Here also do a simple echo output

<?php
declare (strict_types = 1);

namespace app\listener;


class UserLogin
{
    /**
     * Event listening and processing
     *
     * @return mixed
     */
    //Method is your event class
    public function handle(\app\event\UserLogin $event)
    {
        //Output event class
        echo $event->index();
        echo 'Listening completed'.'</br>';
    }
}

Then you can do a simple test and create a controller

<?php
namespace app\controller;

use app\BaseController;

use think\facade\Event;

class Index extends BaseController
{
    public function test()
    {
        //The following sentence is manual registration. If you have not bound it in app\event.php, you need to register manually
        //I haven't used this method because I've bound it
        //Event::listen('UserLogin','app\listener\UserLogin');

        //The trigger event class can also be triggered through the helper function event('U ')
        Event::trigger('U');
        echo 'Run complete';
    }
}

The next step is the operation result, so that even if a basic event class is completed, it can be adjusted according to your business needs

The Event method can pass parameter variables

  However, if there are multiple events, it will be very troublesome. You need to generate multiple listening classes to listen and trigger, so there is another way

Subscription class

Next, let's talk about my simple understanding of subscription classes

A subscription class can listen to multiple events in a listening class

Or generate a file in app\subscribe\User from the command line

php think make:subscribe User

Don't forget to bind app\event.php after generation

<?php
// Event definition file
return [
    'bind'      => [
    ],

    'listen'    => [
        'AppInit'  => [],
        'HttpRun'  => [],
        'HttpEnd'  => [],
        'LogLevel' => [],
        'LogWrite' => [],
    ],

    'subscribe' => [
        'app\subscribe\User',
    ],
];

Of course, you can also use dynamic registration

//Dynamic registration
Event::subscribe('app\subscribe\User');

It is also a simple output

<?php
declare (strict_types = 1);

namespace app\subscribe;


use think\Event;

class User
{
    //The naming specification of the method for listening to events is on + event ID (hump naming),
    //If you want to add event prefix IDS uniformly, you can define the eventPrefix attribute.
    //protected $eventPrefix = 'User';
    public function onIndex()
    {
       echo 'index';
    }

    public function onLogin()
    {
        echo 'login';
    }
    
    //If you want to customize the subscription method (or method specification), you can define the subscribe method implementation.

    //This conflicts with the above eventPrefix. You can only select one to use. I choose custom
    public function subscribe(Event $event)
    {
        $event->listen('Index',[$this,'onIndex']);
        $event->listen('Login',[$this,'onLogin']);
    }
}

  Here, even if the subscription class is completed, the controller uses the following methods when calling the subscription event

Event::trigger('Login');

The running result is

  The subscription class is easier than the listening class and event class. The above is my understanding of event, listening and subscription. If there is any mistake in my understanding, please give me some advice