yii20項目源碼下載

『壹』 yii中顯示yii\web\notfoundhttpexception錯誤怎麼解決

頁面沒找到，自己配置的文件么

果你想顯示一個錯誤頁面告訴用戶請求是無效的或無法處理的， 可簡單地拋出一個 HTTP exception異常， 如 yii\web\NotFoundHttpException。 錯誤處理器會正確地設置響應的HTTP狀態碼並使用合適的錯誤視圖頁面來顯示錯誤信息。
use yii\web\NotFoundHttpException;
throw new NotFoundHttpException();

你應該是use這個了吧

『貳』 如何使用yii2開發

1.安裝php環境（略過，自行網路）

2.安裝代碼編輯器（略過，都非常簡單）

3.下載Yii2.0高級框架

『叄』 yii2.0開源項目下載完之後怎麼用啊 不知道每個文件夾都是幹嘛的

forName支持數組類型，loadClass不支持數組 一般情況下，這兩個方法效果一樣，都能裝載Class。但如果程序依賴於Class是否被初始化，就必須用Class.forName(name)了。 例如，在JDBC編程中，常看到這樣的用法，Class.forName("com.mysql.jdbc.Driver")

『肆』 各位，在Yii框架下，有使用過redis的嗎

安裝redis擴展：
1.通過composer進行安裝，到項目根目錄cmd運行（推薦）
php composer.phar require --prefer-dist yiisoft/yii2-redis

或者添加
"yiisoft/yii2-redis": "~2.0.0"

到對應項目的composer.json文件中
2.手動安裝
點擊下載：yii2.0-redis擴展
把下載的擴展文件放到vendor/yiisoft/下，命名為yii2-redis
修改vender/yiisoft/下的extensions.php，加入redis擴展
'yiisoft/yii2-redis' =>
array (
'name' => 'yiisoft/yii2-redis',
'version' => '2.2.0.0',
'alias' =>
array (
'@yii/redis' => $vendorDir . '/yiisoft/yii2-redis',
),
),

『伍』 yii 框架用什麼開發工具開發比較好比如Zend Studio 之類的開發工具

我用yii開發也有2年時間了，不建議用Eclipse一族的東西（包括 Zend Studio），代碼格式化，Debug還有API提示都馬馬虎虎。我平時用NetBeans，但有一點問題，如果文件多了會比較卡。所以是vim和netbeans混合用。

『陸』 yii框架調用介面代碼一般放在哪個目錄下

1，項目目錄結構分析

2，Yii入口文件分析

在Yii啟動項目時，傳遞了項目主配置文件數組，那麼Yii會在整個應用中綁定一個全局的Yii對象並且可以通過如下方法來調用該對象：Yii::app()
Yii系統把配置文件中的數組值，通過鍵值對的形式綁定到了該對象上，例如在配置文件中我們配置了：
'name'=>'My Web Application',
那麼我們在項目的任何一個地方通過該對象的屬性就可以獲取到「name」的值，方法為：
Yii::app()->name;
3，Yii路由設置

同時應該知道：對於控制器名，Yii首先會檢測當前的控制器名是否是一個「模塊名」，如果是模塊名則先定位到模塊。
「模塊」會在後面搭建項目的時候解釋。
通過上面的路由訪問到的就是：SiteController.php類文件下的SiteController類中的actionIndex方法
控制器文件位於：protected/controllers 目錄下，也就是我們的控制器文件存放目錄
注意Yii中控制器文件和動作方法名的書寫方式，控制器有統一的後綴」Controller「，動作方法也有統一的前綴」action「，同時要求動作方法名的命名規范符合」除第一個單詞外其它每個單詞的首字母要大寫「
由於Yii默認的控制器名為：site
默認的動作名為：index
因此上述通過指定控制器名動作名訪問的路徑和直接訪問：http://localhost/testyii/ 的效果是一致的
4，視圖調用

在動作方法中，調用：$this->render('index');
來為對應的動作方法指定視圖文件，視圖文件位於：protected/views/site 目錄下
其中：site為對應的控制器名文件夾，每個控制器名在視圖中都應該具有一個唯一的文件夾名與其相對應
然後在動作方法中通過『index'來指定顯示的具體視圖文件是site控制器下的指定的『index.php'視圖文件
另外還需要注意：
調用視圖的方法有兩個：
$this->render ----> 會調用模板文件
和
$this->renderPartial -----> 不會調用模板文件
它們之間的區別，也如上所述。

『柒』 請教 關於 許可權判斷 admin

說到CMS，最需要有的東西就是許可權控制，特別是一些復雜的場景，多用戶，多角色，多部門，子父級查看等等。最近在開發一個線下銷售的東東，這個系統分為管理員端，省代端，客戶端，門店端，銷售端， 部門端，部門老大下面分子部門等等，惡心的需求。我們這個項目使用yii框架開發，yii在php屆還是比較流行的，雖然說laravel現在橫行，但是一些部門一些團隊還是採用了yii框架，比如我們。 我是剛接觸yii這個框架，開始的時候對這種面向組件的框架甚是別扭。當時打算自己寫許可權的，自己創建許可權表，關聯表等，但是學習使用yii開發文檔後，發現有個許可權控制RBAC，藉助於yii-admin可以實現完美的許可權，菜單的控制。這篇博客分兩部門，第一部分我會講述怎麼搭建許可權管理包括：安裝yii-admin，創建許可權表，使用許可權控制菜單和訪問許可權等基本的操作，這部分大致說一下，想要看更詳細的步驟可以參考這個比較詳細的講解：/yiisoft/yii2 yii2-admin:https://github.com/mdmsoft/yii2-admin 當然你可以使用composer來安裝，這樣最好不過，如果你安裝好了yii，你就可以切換到項目目錄下，直接執行下面的命令： php composer.phar require mdmsoft/yii2-admin "~2.0" php composer.phar update 然後配置中加入yii-admin的配置項，值的注意的是如果yii2-admin配置在common目錄下是全局生效，那麼你在執行命令控制台的時候就會報錯，所以應將許可權控製作用於web模塊，我們這個項目沒有使用高級模板，所以你可以直接把配置寫在config下面的web.php中，配置如下： 先定義別名： 'aliases' => [ '@mdm/admin' => '@vendor/mdmsoft/yii2-admin', ], 在moles中添加admin組件： 'admin' => [ 'class' => 'mdm\admin\Mole', 'layout' => '@app/views/layouts/main_nifty',//yii2-admin的導航菜單 ], 添加添加authManager配置項： 需要強調的是，yii中的authManager組件有PhpManager和DbManager兩種方式，這兩種方式是由區別的，PhpManager將許可權關系保存在文件里，DbManager方式,將許可權關系保存在資料庫。我們採用保存在資料庫中的方式。 'authManager' => [ 'class' => 'yii\rbac\DbManager', // or use 'yii\rbac\DbManager' ], 添加as access： 'as access' => [ 'class' => 'mdm\admin\components\AccessControl', 'allowActions' => [ // add or remove allowed actions to this list // 'admin/*', //'*', 'site/*', 'api/*', ] ], 需要說的是未知不要放錯了，如下圖所示： 2、配置資料庫許可權表 這一步不用自己去寫，命令行切換到yii2目錄，執行下面命令，創建rbac需要的表，但是資料庫需要自己創建名字是：yii2basic，如果要執行命令，就需要把你剛下配置好的配置文件在在console.php中也寫一份，如果執行不成功，可以吧生成數據表的腳本拿出來自己執行。 yii migrate --migrationPath=@yii/rbac/migrations yii migrate --migrationPath=@mdm/admin/migrations 如果執行成功會生成5張表，還需要一張user表，你可以自己添加 menu //菜單表 auth_rule //規則表 auth_item_child //角色對應的許可權，parent角色，child許可權名 auth_item //角色、許可權表,type=1表示角色,type=2表示許可權 auth_assignment //角色與用戶對應關系表 如果全部成功的話，再訪問index.php?r=admin 就可以了看到許可權的控制可視化頁面，如果出錯，你認真查看錯誤原因，基本上都是配置不對。配置好的話，訪問其他頁面就沒有許可權了，然後你可以修改as access中的allowActions，在開發api或者一些共用的模塊的時候很有用，因為這些頁面不需要進行許可權的控制。 許可權控制頁面如下圖： 3、進行菜單控制 要進行菜單控制，就需要用到剛才創建的那幾個表中的menu表，左側的導航按照我們的設計應該可以通過許可權進行控制，寫死的導航不能達到目的，可擴展行還不強，所以菜單控制必須要支持。 需要注意的是，如果你的後台框架中用到了自己的layout，你需要自己去指定，我們這個項目就是，有我們自己的layout，上面再添加admin組件的時候已經添加了： 'layout' => '@app/views/layouts/main_nifty', 然後我們操作菜單列表。添加菜單項，然後在打開layout文件，其實獲取菜單的邏輯已經寫好了，在MenuHelper中，添加命名空間mdm\admin\components\MenuHelper; 然後注銷原來的導航，添加下面的代碼，基本上就可以實現許可權-用戶-導航的控制了。 echo Nav::widget( [ "encodeLabels" => false, "options" => ["class" => "sidebar-menu"], "items" => MenuHelper::getAssignedMenu(Yii::$app->user->id), ] ); 好了說完了，最後看一下這個頁面： 二、yii-admin優化和重寫 在使用的過程中，yii-admin實現的導航許可權控制遠不能滿足我們的需求，並且，這種組件試的開發，每個操作是完全獨立的，比如，檢查許可權，取菜單，取用戶信息，每個操作都需要執行SQL來進行下面是正常的檢查許可權和得到菜單的sql執行過程。其實這個過程是極其費時的，當用戶量比較多，菜單比較大，許可權表中的數據非常多的時候是不能這樣乾的，使用我們自己的sql檢測工具可以看到，這個過程執行了20條之多的sql語句： 在圖中可以看出，許可權檢查涉及了14次的sql查詢，菜單涉及了5次sql查詢，如此多的sql 執行一旦上線事沒有什麼並發可言的。yii-admin這個組件提供了方便的許可權控制，菜單控制，但是性能上面我們不敢苟同。查看源碼你就知道，這個組件在我看來是一個解耦比較高的組件，每個成分之間可以單獨的使用，這就需要每個操作必須要有自己獨立的資料庫來源，說白了就需要每次都執行sql去取到想要的值，中間很少使用連表查詢這樣的sql，其實10條sql做的功能，在耦合上網情況下，一條sql就搞定了。 像我這種人是不能忍受這么多不相關的sql執行的，所以我就在根源上面修改了yii-admin的許可權檢查部分，修改的方法是我自己想的，不一定對，也不一定適合所有的場景，下面就寫出來與大家分享。 1、菜單的優化 我們通過查看菜單的生成過程大致會執行了5條以上的sql，這個還算可以，我沒有做sql上的優化，原因是我們的菜單是要對應不同的角色和子父級關系，在原來的基礎上我添加了一個type來區分是那種角色能看到這種菜單，一級哪種角色對應某一個菜單顯示的層級關系。這樣管理員，省代用戶，客戶都會呈現不同的菜單。即使配置相同的許可權，不同層級的用戶也會看到不同的菜單。 我們的優化是緩存菜單的生成數據，我們這個菜單是定製的，沒有採用一開始配置的Nav::widget來呈現，而是我們自己循環層級關系，這樣雖然麻煩，但是能很好的提取菜單中我們需要的沒一個邏輯，比如：麵包屑的自動生成，就可以每次提取菜單的label，再比如子頁面，不同控制器下得左導航的高亮，下面是代碼，php和html混寫了，以後會慢慢的提取。 <ul class="nav nav-list"> <?php $idx = ; $request_url = '/' . $mod_id . '/' . $con_id . '/' . $act_id . '/'; foreach ($menus_new['list'] as $label => $menu): ?> <?php if (empty($menu['label']) && empty($menu['url'][])) { continue; } ?> <?php if(!isset($menu['items'])):?> <li class="<?php if (isset($menu['openurl']) && strstr($menu['openurl'], $request_url)) { echo 'active'; $breadcrumb[] = $menu['label']; } ?>"> <a href="<?php echo $menu['url'][] ?>"> <i class="menu-icon fa fa-<?php echo $menu['icon'] ?>"></i> <span class="menu-text"> <?php echo $menu['label'] ?> </span> </a> <b class="arrow"></b> </li> <?php else:?> <li class="<?php if (isset($menu['openurl']) && strstr($menu['openurl'], $request_url)) { echo 'open'; $breadcrumb[] = $menu['label']; } ?>"> <a href="index.html"data-target="#multi-cols-<?php echo $idx ?>"class="dropdown-toggle"> <i class="menu-icon fa fa-<?php echo $menu['icon'] ?>"></i> <span class="menu-text"> <?php echo $menu['label'] ?> </span> <b class="arrow fa fa-angle-down"></b> </a> <b class="arrow"></b> <ul id="multi-cols-<?php echo $idx ?>" class="submenu"> <?php foreach ($menu['items'] as $label => $menu): ?> <?php if (empty($menu) !is_array($menu)) { continue; } if(!isset($menu['items'])):?> <li class="<?php if (isset($menu['openurl']) && strstr($menu['openurl'], $request_url)) { echo 'active'; $breadcrumb[] = $menu['label']; } ?>"> <a href="<?php echo $menu['url'][] ?>"> <i class="menu-icon fa fa-caret-right"></i> <?php echo $menu['label'] ?> </a> <b class="arrow"></b> </li> <?php else:?> <li class="<?php if (isset($menu['openurl']) && strstr($menu['openurl'], $request_url)) { echo 'open'; $breadcrumb[] = $menu['label']; } ?>"> <a href="#" class="dropdown-toggle"> <i class="menu-icon fa fa-caret-right"></i> <?php echo $menu['label'] ?> <b class="arrow fa fa-angle-down"></b> </a> <b class="arrow"></b> <ul class="submenu"> <?php foreach ($menu['items'] as $label => $url): ?> <?php if (empty($url) !is_array($url)) { continue; } ?> <li class="<?php if (isset($url['openurl']) && strstr($url['openurl'], $request_url)) { echo 'active'; $breadcrumb[] = $url['label']; } ?>"> <a href="<?php echo $url['url'][] ?>"> <i class="menu-icon fa fa-caret-right"></i> <?php echo $url['label'] ?> </a> <b class="arrow"></b> </li> <?php endforeach ?> </ul> </li> <?php endif?> <?php endforeach ?> </ul> </li> <?php endif?> <?php $idx++; ?> <?php endforeach ?> </ul> 這個導航是我自己改了好多版總結出適合我們自己的方案，其中breadcrumb是控制麵包屑的顯示，有時間我會抽離php。我介紹的是菜單優化，現在才完成了第一步，菜單的顯示，說到優化我是採用緩存菜單數據的策略，就是緩存上面那個$menus_new['list']，策略如下： 這個策略使用角色緩存數據，就是使用每個角色的許可權加上uid和環境配置MD5以後生成key，考慮到用戶比較多每個用戶都緩存的話開銷太大，並且用戶相同許可權的的比較多，特殊許可權的可以特殊對待，這樣省去了存儲好多重復的數據，環境配置是區分線上數據和測試數據，便於我們進行調試。 過期機制：更重要的是緩存的過期機制，緩存有了但是當菜單或者許可權發生變化的時候就要更新緩存，這里我們引入了版本的概念，能做到緩存變更的最小開銷。比如菜單變化，所有人導航都應該修改，這里我們在redis中加入一個導航版本的變數，每次讀入緩存的時候都會先判斷這個版本與緩存中自己存儲版本是否一致，如果一致證明導航沒有變化，如果不一致認為菜單有修改，導航已過期，需要重新得到緩存，這樣相同的角色，只要有一個人更新了導航，其他人下次再進來的時候就會訪問到最新的導航（統一角色）。這個全局的redis變數會在導航變更和許可權變更的時候自動加1，保證版本的變化，這樣如果有4類角色，幾萬人的用戶，實際的數據修改只發生的4次（實際會比這個多，比如同一個角色不同的許可權，那麼他對應的redis key 就不一樣，它需要自己去取緩存）。具體的代碼實現如下： $user_id = Yii::$app->user->id; $breadcrumb = []; $menus_new['list'] = MenuHelper::getAssignedMenu($user_id); $redis_key = MenuHelper::getMenuKeyByUserId($user_id); $redis_menu = Yii::$app->redis->get($redis_key); $redis_varsion = getVersion(); if (!empty($redis_menu)) { $menus_new = json_decode($redis_menu, true); $old_version = isset($menus_new['version']) ? $menus_new['version'] : ''; //判斷菜單的版本號，便於及時更新緩存 if (!isset($menus_new['list']) empty($old_version) intval($old_version) != $redis_varsion) { $menus_new = getMenu($user_id, $redis_varsion, $redis_key); $log = json_encode([ 'user_id' => $user_id, 'varsion' => $redis_varsion, 'redis_key' => $redis_key, 'value' => $menus_new ]); writeLog($log, 'update_menu'); } } else { $menus_new = getMenu($user_id, $redis_varsion, $redis_key); } function getMenu($user_id, $varsion, $redis_key) { $menus_new['list'] = MenuHelper::getAssignedMenu($user_id); $menus_new['version'] = $varsion; Yii::$app->redis->set($redis_key, json_encode($menus_new)); Yii::$app->redis->expire($redis_key, 300); return $menus_new; } //設置更新key便於時時更新redis function getVersion() { $version_key = Yii::$app->params['redis_key']['menu_prefix'] . md5(Yii::$app->params['redis_key']['menu_version'] . Yii::$app->db->dsn); $version_val = Yii::$app->redis->get($version_key); return empty($version_val) ? 1 : $version_val; } 生成key和更新key的邏輯如下： /** * get menu one user by the id * @param $user_id * @return key string */ public static function getMenuKeyByUserId($user_id) { if (empty($user_id)) { return false; } $list = (new \yii\db\Query())->select('**') ->from('**') ->where(['user_id' => $user_id]) ->all(); if (empty($list)) { return false; } $role_str = ''; foreach ($list as $key => $value) { $role_str .= $value['item_name']; } $redis_key = Yii::$app->params['key'] . md5($role_str . Yii::$app->db->dsn); return $redis_key; } /** * 修改菜單更新狀態，更新redis */ public static function UpdateMenuVersion() { $version_key = Yii::$app->params['key'] . md5(Yii::$app->params['key'] . Yii::$app->db->dsn); $version_val = Yii::$app->redis->get($version_key); if (empty($version_val)) { $version_val = '1'; } else { $version_val++; } $log = json_encode([ 'user_id' => Yii::$app->user->id, 'version_key' => $version_key, 'version_val' => $version_val ]); writeLog($log, 'update_menu_version'); Yii::$app->redis->set($version_key, $version_val); } 2、導航的高亮，圖標，是否顯示 默認的導航高亮是按照模塊，控制器，方法來進行直接匹配的，這樣一來有一種需求無法滿足，比如：A控制器下得頁面下載B控制器下面高亮，這種事無法實現的，所以要修改他們高亮機制。我們沒有再採用他的高亮邏輯，而是自己實現了一個新的邏輯。我首先把要高亮的頁面url加入到菜單的data裡面，data是一個json數據，如下所示： {"icon": "fa fa-home", "visible": true, "openurl":"/web/site/index/"} 這樣我們通過openurl就能知道哪個導航高亮，在頁面中直接判斷當前請求的url在不在這個openurl裡面就可以，但是這樣做有缺點，必須要有把高亮的頁面加入到要高亮的導航裡面，如果頁面太多這種方式不怎麼好，但是我沒有想到更好的方法去解決，如果哪位大神有好的方法可以在中寫出，非常感謝。 圖標和可見性的控制可以藉助於MenuHelper中getAssignedMenu的回調方法實現，你可以在調用該方法的時候傳入回調方法，我直接寫的匿名方法，添加在了該方法裡面，如下所示： $user_type = Yii::$app->user->identity->type; $customer_id = Yii::$app->user->identity->customer_id; $callback_func = function($menu) use ($user_type, $customer_id) { $data = json_decode($menu['data'], true); $items = $menu['children']; $return = [ 'label' => $menu['name'], 'url' => [$menu['route']], ]; $return['visible'] = isset($data['visible']) ? $data['visible'] : ''; //菜單隱藏的邏輯 if (empty($return['visible'])) { return false; } $return['icon'] = isset($data['icon']) ? $data['icon'] : ''; //控制菜單打開的邏輯 $return['openurl'] = isset($data['openurl']) ? $data['openurl'] : ''; $items && $return['items'] = $items; return $return; }; 3、重寫許可權檢測 剛才已經說了，yii-admin 的許可權檢測執行太費時間，執行SQL太多，所以我打算重寫他的許可權檢查的方法，通過讀源碼可以看到，他們檢查是通過user中的can方法調用的，然後通過mdm\admin\components\AccessControl中的beforeAction實現的，我們可以看一下： /** * @inheritdoc */ public function beforeAction($action) { $actionId = $action->getUniqueId(); $user = $this->getUser(); //預留系統檢查許可權的邏輯，一旦重寫檢查許可權失敗，調用系統檢查許可權的方法 if ($user->can('/' . $actionId)) { return true; } $obj = $action->controller; do { if ($user->can('/' . ltrim($obj->getUniqueId() . '/*', '/'))) { return true; } $obj = $obj->mole; } while ($obj !== null); $this->denyAccess($user); } 因為全許可權的檢查包含了子父級檢查，也就是說 /admin/menu/update的許可權是對/admin/menu/* 和/admin/* 和 /*都可見的，所以我們會看到$user->can的調用會使用do -while來進行，這樣就增加的檢查的復雜度，執行的sql就會批量的增加，你想啊，沒一個父級的檢查都是一次全新的函數調用，所以最惡心的也莫過於此了，感興趣的同學可以去看看他的這個過程，當你自己調用這個函數檢測的時候就會發現，執行的sql不是一般的多。 下面是我的重寫方法，一條SQL，兼容了許可權，角色，批量檢查和未登錄用戶的許可權檢查，具體實現如下： /** * 許可權判斷方法 (先不要使用該方法，用的系統方法，效率極低，等有時間重寫之後再用) * @param string/array $permission_name 許可權值（URL 或者 許可權名）/批量檢測可以傳入數組 * @param int $user 用戶id，不傳值會取當前的登陸用戶 * @return boolen * @author zhaoyafei */ public static function permissionCheck($permission_name, $user = 0) { //檢查是否登陸過 if (Yii::$app->user->isGuest) { Yii::$app->response->redirect('/site/login'); } if (empty($permission_name)) { return false; } if (empty($user)) { $user = Yii::$app->user->id; } //管理員許可權不能直接返回true，會存在管理員type = 1分到非管理員許可權的人員（有坑） //匿名方法，處理管理員返回值的情況 /*$setAdminSet = function($param) use ($permission_name) { $paramtmp = $permission_name; if (is_array($paramtmp)) { if (count($paramtmp) == 1) { return true; } $paramtmp = array_flip($paramtmp); foreach ($paramtmp as $key => &$value) { $value = true; } } else { $paramtmp = true; } return $paramtmp; };*/ //檢查是否是管理員, 管理員都有許可權 /*if (empty($user)) { $user = Yii::$app->user->id; $user_type = Yii::$app->user->identity->type; if ($user_type == TYPE_ADMIN) { return $setAdminSet($permission_name); } } else { $user_sql = "SELECT type FROM xm_user WHERE id = :id"; $user_info = Yii::$app->db->createCommand($user_sql)->bindValue(":id", $user)->queryOne(); if (empty($user_info)) { return false; } if ($user_info['type'] == TYPE_ADMIN) { return $setAdminSet($permission_name); } }*/ //根據用戶去取許可權 $permission_list = []; $sql = "SELECT xc.child, xc1.child as role_name FROM xm_auth_assignment xa INNER JOIN xm_auth_item_child xc ON xa.item_name = xc.parent LEFT JOIN xm_auth_item_child xc1 ON xc.child = xc1.parent WHERE xa.user_id = :user_id"; $permission = Yii::$app->db->createCommand($sql) ->bindValue(":user_id", $user) ->queryAll(); if (empty($permission)) { return false; } //組合許可權列表 foreach ($permission as $key => $value) { if (!empty($value['child']) && !in_array($value['child'], $permission_list)) { $permission_list[] = $value['child']; } if (!empty($value['role_name']) && !in_array($value['role_name'], $permission_list)) { $permission_list[] = $value['role_name']; } } //匿名方法，處理子url生成 $getUrlList = function($url) { if (!strstr($url, '/')) { return [$url]; } $url = '/' . trim($url, '/'); $params = explode('/', $url); $param_arr = []; $param_str = []; if (!empty($params) && is_array($params)) { foreach ($params as $key => $value) { if (!empty($value)) { $param_arr[] = $value; } } } if (!empty($param_arr)) { $tmp_str = ''; $param_str[] = $url; $count = count($param_arr); //生成子父級關系 for ($i = $count -1; $i >= 0; $i--) { $tmp_str = '/' . $param_arr[$i] . $tmp_str; $chold_url = str_replace($tmp_str, '/*', $url); if (!in_array($chold_url, $param_str)) { $param_str[] = $chold_url; } } } return $param_str; }; //拼接檢查數據，兼容單傳和傳輸組的情況 $check_list = []; if (is_array($permission_name)) { foreach ($permission_name as $key => $value) { $check_list[$value] = $getUrlList($value); } } else { $check_list[$permission_name] = $getUrlList($permission_name); } if (empty($check_list)) { return false; } //批量檢查是否有許可權 $ret = []; foreach ($check_list as $key => $value) { $ret[$key] = false; foreach ($value as $k => $v) { if (in_array($v, $permission_list)) { $ret[$key] = true; break; } } } //兼容一維數組 if (count($ret) == 1) { $ret = array_values($ret); return $ret[0]; } return $ret; } 需要說明的是，注釋掉的部分是管理員的許可權檢查，如果是管理員會自動返回所有的許可權，但是這種不太好，因為實際情況中會分多種管理員，這樣管理員不一定擁有所有的許可權，如果這樣不是超級管理員就不能使用，所以用的時候還是要慎重，最好統一使用許可權檢查。如果感覺那個SQL執行太慢可以添加緩存，緩存過期的時間和菜單過期類似，當用戶的許可權有變動的時候和菜單修改的時候跟新緩存。兩一種解決辦法是把這個方法協程單利，利用單利只是執行一次許可權的查詢，檢查的階段可以單獨寫成方法提供。

『捌』 那位高手能不能提供一個PHP的項目完整源代碼或者開源的php項目鏈接，讓我能夠參考或者學習一下。

找個框架研究吧.國內thinkphp, 國外zend, ci, yii...

『玖』 YII框架和THINKPHP的區別

這不是一篇評測文章。只是我的喃喃碎語，不計較真。而且，下面的內容真的會很雜，不全面，而且你不可能有和我一樣的開發經歷。所以對於某些我醉心的特性，你可能不會理解。同樣的，我也不可能全部理解你為何對某一項特性十分喜歡。
關於ThinkPHP（以下簡稱TP）和Yii Framework（以下簡稱Yii）的背景、作者和速度方面就不涉及了。因為速度是一個很復雜的問題，牽扯的因素很多。我不得不承認ThinkPHP是 一個是國內框架運營方面的榜樣（當FleaPHP/QeePHP最火的那陣，我說過FleaPHP/QeePHP會倒的）。
運行環境：
Windows NT ACER 5.1 build 2600 (Windows XP Professional Service Pack 3) i586
Apache/2.2.14 (Win32) DAV/2 mod_autoindex_color PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1
Mysql 5.1.4
下載的代碼：
ThinkPHP 2.1，帶擴展、示例和文檔完整包，發布於2011年5月1日，下載地址是 http://thinkphp.cn/Down/download/178
Yii 1.1.7，內含框架、實例和環境檢測，下載地址 http://yii.googlecode.com/files/yii-1.1.7.r3135.tar.gz 文檔需要另外下載
中文化方面，TP和Yii都可以滿足中文用戶的需求。但是由於Yii是國際化的項目，所以代碼的注釋仍舊是英文。不過兩個框架的作者都是國人（沒錯，Yii作者的國籍仍舊是中國），所以交流起來還是很方便的。
是Yii自帶了一個環境檢測腳本，可以告訴你當前的主機環境是否滿足Yii的需求。檢測的內容也比較詳細。我覺得這點比較方便。TP最低需要PHP5.0支持，而Yii最低需要PHP 5.1.0支持。由於我使用PHP 5.3，所以對我來說沒有什麼區別。
Yii是純面向對象的的框架，而TP提供了一系列單字母函數。相比之下我更喜歡Yii的方式，因為可以避免項目之間的沖突。
TP在以前的版本的基類Base類，當時就和一個整合Ucenter時的類沖突了，一度很苦惱。現在TP的各種基類仍舊是直接命名，如Think 類。在項目開發過程中就會體會命名沖突的痛苦之處。Yii則在框架的類都加上了C前綴（介面是I前綴），有效地避免了這個問題。Yii中的 CComponent是所有類的基類，可以看看CComponent的代碼，很有用。
說到命名問題了，就不得不說自動導入的問題。TP的類導入和Yii的代碼風格差不多。但是Yii還支持PHP的命名空間和自定義autoload方法。
TP有個特色叫項目編譯。我覺得與其使用項目編譯，還不如使用APC。在Yii中也有個yiilite.php文件，裡面就包含了Yii的所有核心類。Yii作者表示在沒有APC的情況下，還是不要使用這個「編譯」好的文件，因為反而會增加系統開銷。
TP中還在第一次訪問的時候自動生成項目，我覺得這一點和自動編譯一樣，都是我不喜歡的。我對每添加一個if都很敏感，這種判斷讓我很糾結。比如說 TP在每次運行的時候都要檢測PHP版本，而Yii則單獨做了一個內容更詳細的環境監測腳本。我既然要用這個框架，我在第一次使用的時候，肯定就知道能不 能在當前環境上使用了，為什麼要每次都要檢測呢。當時我就說過，TP為用戶做了太多事情。比如舊版本中的TopN函數。
Yii的組件思路是非常不錯的，用起來十分地舒服。從session到cache，你可以無縫地更換所有的組件而無需重構項目。而且Yii的延遲加 載也做得比較徹底，每個組件都是用到的時候才載入。比如，TP中，如果配置了session自動打開，則TP在應用初始化的時候執行 session_start()。而Yii則是你用到session的時候才打開session。
說到項目的配置文件，TP要求是config.php，而Yii則比較靈活，支持多配置文件。
當初TP很推崇自己的ThinkAjax，現在也改用JQuery。這一點是進步。
TP做了很多小實例，這一點值得Yii學習。Yii在這一方面正在有一個叫yii playground的實例網站在開發中（http://code.google.com/p/yiiplayground/）。
TP的動態模型可以實現不需要定義Model。但是在實際的項目中，我更傾向於使用Yii的方式。順便說一句，將label定義在model中，為我的日常開發帶來了許多方便之處。
剛才提到TP的項目自動生成，Yii中也有這種工具。而且比起TP，Yii的工具更加強大而且可擴展。
從TP的代碼中，有人可以看出其作者熟悉JAVA。而從Yii的代碼中，有人會發現其作者熟悉.Net。這常常是我身邊人看到代碼的時候發生的小插曲。
Yii封裝了大量的頁面控制項和類庫，也是Yii如此吸引我的一點。這是TP短期無法比擬的，在TP的使用過程中總遇到這樣那樣的問題，讓我感覺TP對我反而是阻礙。而Yii真的是，舒服，實在是太好用了！
無論從代碼規范、設計思路、類庫豐富程度上來說，TP都遠遠不及Yii。有人說你看TP多簡潔，Yii太臃腫了。錯了！簡單和簡潔不是一回事。TP 那叫簡單，你讀讀Yii的代碼吧，那才叫簡潔。至於臃腫，去看看Zend Framework就知道了。（順便說一句，我很喜歡Zend Framework，它是學習設計的典範）
說到讀代碼。對於程序員真的很難嗎？讀寫得好的代碼應該是一種享受才對。Yii的學習曲線是比TP高那麼一點點，但是對比Yii的巨大優勢而言不算什麼了。而且，我認為在遇到學習困難就退縮或者認為Yii就像天書一樣的人，還是轉行吧。
以上是應一篇評論所寫的。對比TP1，現在的TP2的確有了很多進步，但是還是存在一些問題。對比Yii……，TP真的沒有可比的能力。抱歉讓TP的fans失望了。
那就下定論了嗎？不，不是的。從類庫到框架，再到解決方案。什麼是最好的？每一個人都有不同發說法，這是因為每一個人的思維習慣不同，遇到的問題不同，問題所在的環境也不同。怎麼能奢求所有人都有同一個選擇呢？
還是那句，適合，就是最好的。對我來說，Yii是最好的。

『拾』 有一套yii框架源碼不會搭建,大神們有沒有教程啊

+我，我們是專業的